Skip to main content ↑ ↓
Topic: Using git pages? (Read 6871 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Using git pages?

Reading this, I started wondering is it wouldn't be better to serve all the "admin_info_files" from github instead of our server, reducing the overhead required for their update.

So I started playing a bit.
Two are the options:
1) use github pages, I set up a branch to test it:
https://github.com/emanuele45/Dialogo/tree/git_pages
and the page are located at:
http://emanuele45.github.io/Dialogo/site/current-version.js
and alike.
2) directly load the files into the repo.

What are the differences.
Github "raw" files (i.e. option 2) are not executable (I mean the javascript files), so they cannot be included and executed in the page like a CDN, though that's not so important because we are already using a scheduled task to fetch these pages. It may become a bit messy if we have them in master, but should work. Alternatively we could set up a separated repo just for that files.

Use pages would allow us not to use fetching if we want, though it's over http, so if a site is on https it wouldn't be loaded (not completely unusual these days), I'm not sure how fetch_web_data works fetching files on http from https.

Of course we could use a mixed approach and defines where "we" (i.e. the forum) are (http/https) and act accordingly, but maybe that's for "later".

Opinions?

ETA: related to https://github.com/elkarte/Elkarte/issues/14
Bugs creator.
Features destroyer.
Template killer.

Re: Using git pages?

Reply #1 –

I'm fine with using Gihtub wherever possible..  That would for sure reduce the server load..  If we put it in a repo we should definitely create a seperate repo for these tasks.

Nonetheless I could offer a european mirror server  ;)
Thorsten "TE" Eurich
------------------------

Re: Using git pages?

Reply #2 –

Yeah, probably make sense.

Name of the repo? Service?
Bugs creator.
Features destroyer.
Template killer.

Re: Using git pages?

Reply #3 –

Don't you need to have versions as part of the URL the way SMF does?

Re: Using git pages?

Reply #4 –

Actually we don't have anything at the moment. lol

When I pushed that commit, I was thinking to let the installed version decide what it wants, if you look at the file I linked (let's not concentrate on the typo :P) is it structured like:
Code: [Select]
window.elkVersion = new Array({
	base: '1.0',
	latest: '1.0 alpha'
});
So I was exploring the possibility to have in that file an array of objects with a "base" version (1.0, 1.1, 1.2, 2.0, etc.) and a latest version for that line, so that it would be elk to decide what is the latest version of the "current" install and not a remote script.

The big advantage would of course be we are serving a static file.

Unless, the most meaningful decision is taken: support only one version at any time. That would make everything much easier. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Using git pages?

Reply #5 –

And I forgot:
QuoteOf course fetch these files from the repo may be against github ToS, actually they say that excessive use of bandwidth may result in the disabling of the account.
Bugs creator.
Features destroyer.
Template killer.

Re: Using git pages?

Reply #6 –

I don't think we would have a bandwidth problem with github for a few lightweight static files, I think a lot of that TOS came about when there were some rather large disto's being served?


Anyway almost seems like using the raw files from a elkarte/site repo would be the best, we just have to,  update them when needed, although I don't think GitHub raw will do a 304 so it will always return the data, maybe pages does?


Thinking  ... Could we also just do site releases, download the zip (all those static files) and update the db as needed?