Hi, All: In previous meetings, we have discussed the wider development team sharing ownership of the CI configuration. In last week's face-to-face, I agreed to investigate further. I have been working with devops to test GitLab/GitHub integration with two sample repositories (gpii-handlebars and gpii-express). After a couple of days of testing things in the background, I've reached a point where I felt it was time to report back to the group.
*TL;DR: I hit a fairly large sticking point in testing GitLab/GitHub integration, and we need to talk about it before I can proceed much further.* First, a bit of good news. Since I worked with Avtar and Alfredo to test GitLab integration during P4A, GitLab has added support for CI/CD-only projects, i.e. projects in which the code lives on GitHub but CI/CD are handled by GitLab. This seems to work well, and updates in a time frame we can live with (minutes rather than the previous hours). Now, the bad news. From what I can see we can't really make use of the built-in GitLab/GitHub CI integration for a very basic reason: In their docs <https://docs.gitlab.com/ce/workflow/forking_workflow.html> and merge request examples <https://docs.gitlab.com/ee/user/project/merge_requests/index.html#use-cases>, they make it pretty clear that they use a different workflow. Whereas we use the "fork and pull request" workflow <https://gist.github.com/Chaser324/ce0505fbed06b947d962>, they prefer submitting pull requests from branches in the same repository. Unfortunately, this worldview is pretty firmly baked into their tools, and our worldview is not supported well at all. Only pull requests created from a branch in the same repository result in automated builds and PR comments. Pull requests created from a GitHub fork only result in builds once they're merged, and never result in PR comments. I also tried forking a repository from within GitLab and using their "Merge Requests" feature. They don't even suggest merging upstream, you have to type in the upstream repo more or less manually. Once you've done that, a pipeline runs, but only relative to your forked project. Since my fork had a .gitlab-ci.yml inherited from the upstream repo, GitLab made the attempt to run builds, but in the forked rather than the upstream project. As there are no runners available in the forked project, the builds ended up being "stuck". GitLab did at least comment about the pending builds on the merge request, but that seems of little use to us, as we have no intention of using GitLab merge requests instead of Github pull requests. There appear to be some options for grouping builds across multiple projects <https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#multi-project-pipeline-graphs>, but however you slice it, it looks like every contributor would have to integrate their GitLab and GitHub forked projects in order to run builds and provide feedback on PRs. This seems unacceptable unless we can somehow automate nearly all of the integration work. Although that alone would be enough to recommend against using GitLab's GitHub integration, it also lacks any real controls over who can trigger a build and when. To build at all you must be a committer to the repo itself. A build is always triggered when there is a commit or PR. There is no mechanism to relaunch a build from the PR itself. I did look briefly at services like IFTTT and Zapier to see if they could somehow bridge the gap. Neither offer the ability to trigger a GitLab CI pipeline, and I couldn't find any other good options. I also looked at Avtar's previous work <https://github.com/avtar/docker-push-ref-gitlab> in P4A. That's promising, as it at least offers a starting point for mirroring forks on GitLab and then setting up runners automatically. A custom webhook also offers the option to limit builds to particular groups or to trigger builds based on comments. I will continue researching and thinking about options, with an eye towards discussing the topic in next week's architecture meeting. Please do comment if you have relative information about possible workarounds (third-party integrators, options for webhooks). Cheers, Tony
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
