Mender blog

How are we migrating from GitHub to GitLab and keeping our loved Open Source workflow

Long story short: we are in the process of migrating our Travis/Jenkins CI infrastructure to GitLab CI while keeping our source code in GitHub and thus the Open Source workflow that we love.

So what is the challenge with it?

At the moment, the GitLab CI integration with GitHub has a limitation that conflicts with our Open Source workflow: it will not run a pipeline for a PR when its origin is from a fork instead of a branch of the repo.

And what have we done to work around it?

We have written a simple bot to deal with this. It is Open Source and written in Golang. Keep reading to know more about it and get inspiration for your project!

The Open Source workflow

We use a wildly extended workflow, where we welcome community contributions to our software repositories. The GitHub workflow that we recommend is to fork our components, add our changes, and then submit a Pull Request to our repo. So far so good.

None of this workflow seemed to be problematic for our GitLab migration: if we just keep our code in GitHub and keep using GitHub’s PR mechanism there, we only need to change the checks reporting from Jenkins/Travis to GitLab, and GitLab had excellent support for GitHub integration

Until we stumbled upon this issue: GitLab will refuse to run the pipelines for PRs coming from repo forks (both for community and developers of our own organization). Seems like we are not the only ones to want this feature, see issue #5667 at GitLab tracker.

A bit about our architecture and CI

To ensure a high quality product, we maintain a good deal of CI infrastructure and automated procedures around the Mender project.

Mender is built following a microservices architecture. For the CI infrastructure, this means that each component (independent of Git repository) has its own QA checks (typically unit tests, code coverage, etc.) which have no sensible secrets. In our old setup, this would be the verification run by Travis.

In addition, we have an integration QA pipeline, with a big number of integration tests and other miscellaneous checks that verify the workings of all the components together. This pipeline, however, contains secrets because of its responsibility for publishing Docker images or uploading artifacts during our releases.

For our migration to GitLab to be complete, we would like to automatically run the single component’s pipelines of all submitted PRs but prevent the main integration QA to run for PRs coming from authors outside of the organization. These will need to be manually triggered once we verify that it doesn’t contain any potentially malicious code.

The workaround: our bot

Back to our challenge. Inspired by Terry Cojean’s suggestion in the issue above, we got our hands on in writing a bot to deal with this limitation. The code, of course, is also Open Source, and the repo is hosted in GitHub.

The idea is the following:

We set an organization-level webhook in GitHub so that any Pull Request activity triggers a POST call to our robot. The robot then triggers the pipeline for that specific component unconditionally. After creating a branch with the changes from the PR, the GitLab pipeline can run normally. In addition, and only when the author is part of our organization, we will trigger the integration Pipeline.

From here, GitLab will take care of updating the test results in the GitHub PR.

The robot is pretty easy to set up in a server: all you need is to compile it from source (go build…), install the binary in some known path, and use few environment variables to pass him the APIs tokens and secrets.

You can set up a systemd service similar to:

[Unit] 
After=mysql.service

[Service]
ExecStart=/usr/bin/env GIN_RELEASE=release 
INTEGRATION_DIRECTORY="/root/integration/" GITHUB_TOKEN=<your GitHub token>
GITHUB_SECRET=<The GitHub secret from the webhook> GITLAB_TOKEN=<Your GitLab
token> GITLAB_BASE_URL=https://gitlab.com/api/v4 
/root/integration-test-runner-gitlab
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bi
n:/usr/games:/usr/local/games:/snap/bin:/root/integration/extra

[Install]
WantedBy=default.target

The implementation is pretty much fitted for our specific needs in Mender and it won’t work out of the box for your project. But we hope that the design can inspire you if you run into the same challenge. And of course, we are always open to receive Pull Requests and listen to your ideas! ;)

Lluís Campos

Recent articles

Key takeaways from embedded world North America 2024

Key takeaways from embedded world North America 2024

The Mender team attended the first embedded world in North America to connect with industry leaders and discuss insights on IoT compliance, the CRA, RTOS vs. Linux for IoT, and the importance of secure OTA update orchestration.
Understanding the EU Cyber Resilience Act (CRA): Why it matters and how to comply

Understanding the EU Cyber Resilience Act (CRA): Why it matters and how to comply

The EU Cyber Resilience Act (CRA) was enacted in October 2024 and has impacted products with digital elements on the European market. Learn why CRA compliance is essential for manufacturers, the penalties for noncompliance, and how to meet the Act's cybersecurity standards.
How OTA updates enhance software-defined vehicles

How OTA updates enhance software-defined vehicles

Discover how OTA updates enhance software-defined vehicles by improving safety, reducing recalls, and delivering benefit to producers and consumers.
View more articles

Learn why leading companies choose Mender

Discover how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices. Focus on your product, and benefit from specialized OTA expertise and best practices.

 
sales-pipeline_295756365