Some notes on CI integration and online documentation - GitLab, GitHub, and Read the Docs

Computational Science
, , ,
1

GitHub

CI Integration

GitHub explicitly states that self-hosted (private) runners should not be used for public repositories. This is because there is no mechanism to prevent someone injecting malicious code in a pull request in an attempt to gain access to the system with the self-hosted runner.

GitHub Pages

GitHub Pages is designed to generate online documentation from Markdown using Jekyll. You can generate the webpages using other tools, but the html must be included in the repository. Some people use a separate repository to hold the generated html in order to avoid polluting their main repository with generated html.

GitLab

CI Integration

GitLab pipelines provide a mechanism for manual triggering, which allows maintainers to control whether a pipeline is run and prevent a malicious PR from executing.

GitLab pipelines for GitHub repos cannot be run for pull requests from forks. GitLab pipelines for GitLab repos can run for merge (pull) requests from forks.

GitLab Pages

GitLab pages support documentation generated in a GitLab pipeline by Sphinx or other documentation tools without polluting the repository with the generated html.

Read the Docs

Documentation must be generated on the Read the Docs servers. They do not allow pushing the html from a CI workflow. They have no intention of changing this because they do not want to be used as a website provider.

2

deal.II and ASPECT both use a model where a maintainer has to set a tag and
insert a magic keyword into a comment for at least some of the runners to
actually test a patch. This works around the issue of security at least to the
degree that a maintainer has to pull the trigger for a particular patch.

Best
W.

3

Wolfgang,
This is correct, but it requires some custom logic and using plugins of Jenkins to work. It seems that Github Actions do not support this at the moment.
Jenkins requires a lot more effort to host and maintain, that is why we talked about switching from Jenkins to Github Actions for the CIG testing.

One could try to create some custom Github Actions code block that checks for the tag in a similar way, but I think the pipeline script itself is not protected (it is for Jenkins, only admins can change it), meaning that a malicious user could just comment this out.