Rémi Dubois and Benoît Suttor: Jenkins Out, GitHub Actions In: How We Made the Leap

Here are the slides.

Legacy setup: single physical server, Ubuntu 14, Jenkins plus a lot of plugins, some Groovy pipelines of varying quality, hard to upgrade.

Why migrate? As you see, the Jenkins server was on its last legs, and we wanted to get more in line with the community. Why not Gitlab CI? We already had GitLab internally, but all Plone products are on GitHub, with all related GitHub Actions knowledge in the community.

We talked to our teams. Does the action workflow still suit your needs? What triggers the CI/CD? What would you improve?

We created the gha repository. This contains reusable composite actions. We use self-hosted action runners. These are defined in Docker images. They contain multiple Python versions, Plone buildout dependencies, etc.

Now a demo. When a PR is merged, a Docker image is built. When ready, it sends a message on Mattermost (similar to Slack). Then the new image is pulled, containers restarted. When a tag is created, this goes to production. We schedule that for the next day at 3 AM.

We kept an eye on observability, like the Mattermost notifications, also in case of problems.

Fun fact: the timing was perfect. The physical Jenkins server died due to disk failure a day before migration completed. We could not safe the data, but it was not needed.

Current WIP feature: shared reusable workflows on an organisation level. Align with plone.meta best practices.