Moving the website to GitHub Pages (Discussion)

srevinsaju commented 3 years ago

I put forward a proposal to move the website to GitHub Pages, after a series of problems on Machine/freedom.

The docker container www-rebuilder doesnt work anymore.
The latest commits, eg: The Flatpak commit by @tchx84 is not deployed yet.
Machine/freedom would probably retire soon.

GitHub Pages has a fast built-in Jekyll Processor, which would automatically build this website and deploy it to https://sugarlabs.github.io/www-sugarlabs. By setting a CNAME on our nameservers, we should be then be able to point www.sugarlabs.org -> https://sugarlabs.github.io/www-sugarlabs. This would bring forth faster builds, Pull Request Previews, and much more.

srevinsaju commented 3 years ago

cc @sugarlabs/sugar-labs-inc

samswag commented 3 years ago

Github pages do have limitations, maybe netlify sounds like a good plan, we can apply for an open source plan.

srevinsaju commented 3 years ago

@samswag May I know what are the limitations of GitHub Pages?

samswag commented 3 years ago

Here you go Netlify Vs Github

srevinsaju commented 3 years ago

Here you go Netlify Vs Github

Interesting, its a feature list provided by Netlify itself.

How would Netlify benefit Sugar Labs over GitHub Pages (considering only Sugar Labs, and the features used by the current website)

Isn't Netlify another level of complexity?
Wouldn't that require additional credentials, which you would need to maintain?
What would happen if the owner of the Netlify repository stops contributing / gets hit-by-a-truck?
Wouldn't it be better if we have all the information at one place?

I have been using Netlify, and GitHub Pages. I feel Netlify has higher performance over all cases, but in the case of Sugar Labs, in my opinion, it looks like an overkill. What do you think?

samswag commented 3 years ago

I totally agree with you, I also believe in future-proofing. The website or at this currently will be changing soon, so maybe in future, some decisions can make us want to port.

Since netlify has what Github pages offer, we can consider that too.

quozl commented 3 years ago

My preference is to scale down the number of different tools to an absolute minimum in line with the number of active developers we have.

We are also an open source project, and as part of our mission should think carefully before using proprietary services, independent of service cost. GitHub is proprietary, and we aren't unduly affected by the proprietary nature of GitHub.

Also, @sugarlabs/sugar-labs-inc only contains two of the current board, so I've not been using it.

samswag commented 3 years ago

Agreed, as per @sugarlabs/sugar-labs-inc I see not in there, maybe @aperezbios can address that.

quozl commented 3 years ago

Per https://github.com/orgs/sugarlabs/people there are plenty of people who can address it. But the board members are the ones obliged to do so.

srevinsaju commented 3 years ago

My preference is to scale down the number of different tools to an absolute minimum in line with the number of active developers we have.

Agreed. We have few sysadmins to actively devote enough time to maintain our own infrastructure. Wherever possible, I feel using GitHub Pages for serverless static page deployment is ok. GitHub Pages does not use any cookies, as compared to Netlify iirc. So privacy-wise, I suppose its okay to not have any other extra addition to the current website (like netlify configuration files, etc.). In future, for example, if we rewrite the website in hugo, (gohugo.io), we can think of another service.

We are also an open source project, and as part of our mission should think carefully before using proprietary services, independent of service cost. GitHub is proprietary, and we aren't unduly affected by the proprietary nature of GitHub.

Agreed.

Also, @sugarlabs/sugar-labs-inc only contains two of the current board, so I've not been using it.

Ok.

rhl-bthr commented 3 years ago

My comments after https://github.com/sugarlabs/www-sugarlabs/issues/333#issuecomment-841637207,

Developers should have to spend minimal time maintaining the website and wiki, and more on building Sugar, Sugarizer, and Music Blocks. GitHub pages should do a good job at reducing maintenance. While GitHub is a proprietary service, this dependency was partly already taken as GitHub is used to host the source code.

View comments with the light that I'm not an active member anymore, and I won't be the developer actually spending time to fix and maintain this

chimosky commented 3 years ago

I think we need to address this as it's lingered long enough, I do agree with moving to Github pages as there will be very little to do about maintenance.

chimosky commented 3 years ago

Closing this as the website has been moved to GH pages.

aperezbios commented 3 years ago

The migration is not successful. The website is still 404 as of just now. This is not complete.

chimosky commented 3 years ago

It works fine for me, can someone else confirm?

rhl-bthr commented 3 years ago

Where is the website building from? https://sugarlabs.org/profiles/ is not updated with my patch 2a40dfb

chimosky commented 3 years ago

Where is the website building from? https://sugarlabs.org/profiles/ is not updated with my patch 2a40dfb

It's building from this repo, I'll check why it's not showing your change later as it was showing it before now.

@srevinsaju seems like the CNAME doesn't currently point to sugarlabs.github.io but dig shows that it does, GH says it doesn't.

srevinsaju commented 3 years ago

% dig www.sugarlabs.org

; <<>> DiG 9.16.16 <<>> www.sugarlabs.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20310
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.sugarlabs.org.             IN      A

;; ANSWER SECTION:
www.sugarlabs.org.      2711    IN      CNAME   sugarlabs.github.io.
sugarlabs.github.io.    2711    IN      A       185.199.110.153
sugarlabs.github.io.    2711    IN      A       185.199.109.153
sugarlabs.github.io.    2711    IN      A       185.199.111.153
sugarlabs.github.io.    2711    IN      A       185.199.108.153

I am getting annoyed with local DNS caches, and I have no clue how to purge them. So, I am not sure if this is my PC alone, it would be nice i someone else could test it.

srevinsaju commented 3 years ago

It's building from this repo, I'll check why it's not showing your change later as it was showing it before now.

It might come from the subsequent commits, as it is just set up today.

srevinsaju commented 3 years ago

oh, nvm. Looks like sugarlabs.org now includes https://github.com/sugarlabs/www-sugarlabs/commit/2a40dfbbd3c3f272ef1c6f6bc74e0c519aca9c1a commit

aperezbios commented 3 years ago

It's working from my location now.

aperezbios commented 3 years ago

Final step is to update the documentation on the wiki, so we have the new process for updating the website actually documented somewhere :)

chimosky commented 3 years ago

Final step is to update the documentation on the wiki, so we have the new process for updating the website actually documented somewhere :)

I think it'll be just to state that all changes are built automatically as we've moved to GH Pages.

srevinsaju commented 3 years ago

Final step is to update the documentation on the wiki, so we have the new process for updating the website actually documented somewhere :)

I have updated the wiki. Removed the obsolete instructions, and added the steps to update the website now.

Basically, to update the website: all we need to do is, to push a commit to master, which will trigger the pipelines to refresh the website.

aperezbios commented 3 years ago

Basically, to update the website: all we need to do is, to push a commit to master, which will trigger the pipelines to refresh the website.

Great. How those pipelines/automation bits actually work is also important to document, so someone who is going in to troubleshoot why that automation might fail is going in fully-armed with the knowledge they need to troubleshoot it without prior knowledge. Are there any explanations or links to how the automation works?

srevinsaju commented 3 years ago

Agreed, you are right. I have added https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll this link to the wiki page to help debug future builds. This link has the entire information on how to set up the continuous integration system, setting up a custom domain, and troubleshooting jekyll builder bugs.

In short, When a user with push access, pushes to the master branch, the following things happen under the hood:

A GitHub builder workflow would be automatically triggered (this workflow is enabled in the repository setting by a repository maintainer, in this case, its @chimosky. It can be disabled from the same Settings > GitHub Pages section )
Jekyll builder is run, and the static files are hosted on GitHub's servers (4 of them, for load balancing), and the CNAME file placed at the root, helps GitHub to tell which custom domain to host it from.
The static files are then displayed by a "Headless CMS", a jamstack service offered for open source as well as private repos, under GitHub.

quozl commented 3 years ago

Consider also how many people have push access now. It is a large list.

srevinsaju commented 3 years ago

Perhaps, we should mark master as a protected branch to restrict the number of users with the ability to deploy the website to the CMS. :thinking:

chimosky commented 3 years ago

Consider also how many people have push access now. It is a large list.

For the website, I've restricted some of the outside collaborators to read only. Also restricted some member access to the needed repos.

sugarlabs / www

Moving the website to GitHub Pages (Discussion) #332