Switch to GH Actions for build and deploy?

[doerners]

Currently the MEI website is build through gh-pages which is enabled by the gh-pages gem in our Gemfile. However, this has the disadvantage that we can only use gems that are whitelisted and are limited to the fixed versions supported by GitHub.

Another possibility for building jekyll sites is through GH Actions, as described on the official jekyll site. Switching to GH Actions would allow to rely on the newest version of jekyll available as well as to include basically any gem we might want. This workflow is also quite common, as there are e.g. various GH Actions already available on GitHub marketplace. This might also solve the discussion/problem around the Gemfile.lock in the context of building the site locally, see #93.

I'm not entirely sure if this approach would be feasible for MEI and if reusing an existing GH Action would be the best approach here. Maybe our GH Actions master @musicEnfanthen does have some advice?

[musicEnfanthen]

Thank you @doerners for the proposal and pointers. I think that is something that could be seriously taken into consideration, as it would allow, for instance, inclusion of jekyll-scholar for bibliographic references (which is not white-listed with the standard gh-pages approach).

In any case, we should fully understand all the consequences first before implementing such a step. E.g., what security reasons are meant, when the official jekyll site says

When building a Jekyll site with GitHub Pages, the standard flow is restricted for security reasons and to make it simpler to get a site setup.

(and how are these security issues addressed (or not) in the GH Actions workflows). Also, it would be good to have a test-repo that allows to test the build process from all perspectives.

If you don't mind, I propose to collect some further opinions for the discussion both here and at the next ODD meeting this week.

[lpugin]

Since building through gh-pages currently works and switching to GH Actions would be one more layer to maintain, I would not change to it unless there is clear need for it. Local issues with the Gemfile.lock does not sounds like one in my opinion. Just my 2 cents...

[doerners]

Thank you both @musicEnfanthen and @lpugin for your comments/insights. To me it sounds like a brilliant idea to discuss this during the next ODD meeting.

[bwbohl]

Thanks for bringing this up! As I'm not aware of the possibilities this would bring us for our website, e.g. by using other gems, could you illustrate some usecase, please?

[doerners]

So one advantage I see is that we could use the current jekyll version which is 4.2.2 while with the current approach the jekyll version is fixed at 3.9.0. Although I'm not sure how necessary it really is to always be up to date with the version, there have been some bug fixes and enhancements introduced with the newer versions as you can see from the changelog, so it might be worth considering.

Currently our bibliography on the website is build with BibBase. To my knowledge there is still no support for different citation styles implemented (this applies to the rendering of the references as well). When dealing with BibBase a while back I had trouble with formatting the BibTeX file, because BibBase behaved differently than I expected and the documentation seemed insufficient to me. Thankfully @musicEnfanthen could fix the mess I made, but it might be worth discussing if switching to another bibliography tool might be an advantage. For jekyll there is this tool called jekyll-scholar which at least supports different CSL styles. We could use this if we decide that it offers the best functionalities, but only if we don't rely on gh-pages.

Furthermore I think it might be a good idea to discuss if we want to offer search capabilities for the whole website to our users. From a usability perspective I think this might really be something to consider. There are some gems out there that are tailored to jekyll like jekyll-lunr-js-search. However, all of those gems I found are not supported by gh-pages.

I think these are the three main points I would think of from the top of my head.

[lpugin]

The website content is pretty basic. Which enhancements do you have in mind?

Using plugins can be quite useful, I agree. Having a website search would be useful too. However, on that topic I would suggest to have the guidelines search working again first. This seems to be of a much higher priority.

[doerners]

tbh I didn't have any enhancements in mind. I just wanted to illustrate that the changelog lists enhancements and bug fixes that have been introduced with newer versions of jekyll but I haven't really checked them out. However, switching to a newer version of jekyll might be necessary if we decide to use other gems. (not sure if this is what you meant)

[rettinghaus]

Thanks @doerners for this great proposal. I don't think it would add a new layer to maintain – on the contrary. If everything is set up, we'll have definitive versions of the used gems pinned in the lock file, so we're independent of the quite unpredictable update behavior GitHub shows on their side. Here the lock file actually makes sense. And if there are some security issues in the gems, dependabot will most likely jump in and save the day. But I agree with @lpugin that the current situation with the search has highest priority.

[annplaksin]

Since @musicEnfanthen and @doerners kindly asked to leave this note... As I mentioned in the ODD meeting, I was able to switch in a GH-Pages deployed website from the gh-pages gem to a vanilla Jekyll gemfile and the site is still deployed via standard GH pages: see here. I tried that after receiving a dependabot vulnerability for cmark-gfm. The fixed version of the gem wasn't available with gh-pages gem.

[rettinghaus]

To not forget about this issue I want to point to this recent update: https://github.blog/changelog/2022-07-27-github-pages-custom-github-actions-workflows-beta/

[musicEnfanthen]

---