Using GitHub Actions for deployment

[bedroesb]

This has surfaced already multiple times, the use of GitHub actions for deployment instead of GitHub Pages, and at this moment it is more appealing then ever. I would like to use this discussion to show how currently RDMkit is deployed, and how it could be using GitHub actions, discussing the pro and cons.

Using GitHub Pages.

Currently, if you want to deploy RDMkit, me as a maintainer or you at your fork, you just have to go to the Pages setting, select "deploy from branch", choose the branch you want to deploy from, and call it a day.

This simplicity is the reason why I kept holding on to the Pages way of deploying for so long.

GitHub Pages does come with some downsides too

• Has a strict set of 'Plugins' it supports and locks the version it uses, for example the scholar plugin is not supported for references
• Makes use of the old Jekyll 3.9 version, and they don't seem to update it because of compatibility reasons, letting us miss out on features
• Does not allow custom scripts

Using GitHub actions

This was in the past not an option for me since it required the use of a separate deployment branch and was less convenient to setup. Things have changed now , for the better. Thus it seems appropriate to give it another chance.

Within the repository pages settings, one can now select GitHub Actions for deployment.

Setting this up for RDMkit is very easy and for the end-user things would look exactly the same. Differences are there when people want to preview their changes on their own fork.

• By default the deployment will happen on the master/main branch and you can not change the branch where it gets deployed from using the Pages setting, but one has to change it in the Workflow file
• By default, GitHub Actions is disabled on forks. To get this working one has to enable it in the Actions setting, not difficult but an extra step.
• if Actions are enabled on the fork, the other workflows will run too. This includes the weekly TeSS, bio.tools and FAIRsharing check which needs credentials using GitHub secrets. When those secrets are not set, a weekly GitHub Action fails will be triggered.

These are only annoyances for people previewing on their own fork, and quite honestly I think me, Flora and Martin are one of the few making use of this feature.

The benefits

• Make use of performance improvements and many new features in the latest Jekylls ( current version locked by GitHub pages is 4 years old)
• Allow for a centralized bibliography using the Scholar Gem and many other Gems
• Support for custom plugins so we can finally make use of the tools-table in a more clever way (linking to it from the content for example)
• This would also fix the random error that appear now when deploying RDMkit or the theme in general (see Random error, is gone when rebuild ELIXIR-Belgium/elixir-toolkit-theme#47)

Considerations

• We should make sure that other deployments of the elixir-toolkit-theme (the one theme used for RDMkit) stay supported if GitHub Pages is used, so they don't break when bumping the version (this would not allow the use of new Jekyll syntax)
• Previewing on your own fork should be better documented on RDMkit (is not documented at all at the moment, probably explaining the limited usage)

[nsoranzo]

If Actions are enabled on the fork, the other workflows will run too. This includes the weekly TeSS, bio.tools and FAIRsharing check which needs credentials using GitHub secrets. When those secrets are not set, a weekly GitHub Action fails will be triggered.

You can easily disable this in the GitHub workflow with something like if: ${{ github.repository_owner == 'elixir-europe' }} at the workflow/job/step level.

[bedroesb]

ok that's great, one downside less ! :D Thanks!

[korbinib]

Previewing on your own fork should be better documented on RDMkit (is not documented at all at the moment, probably explaining the limited usage)

I am not sure how relevant deployment from the own fork is. I feel many (including myself) preview locally if necessary, but I could be wrong. Moving on from Jekyll 3.9 will solve a dependency issue for many, but is then incompatible with a lot of existing GH page specific workflows, which people also might use locally.

[bedroesb]

Well it is especially handy when you wan't to gather opinions about 'website experiences' when a new feature gets added. In theory if a new country page or so gets added, one could preview how it renders... but on the other hand, it is not that people add complex things like tables or many images.

Good point