Giving this a bump ahead of the Arch meeting tomorrow. Thanks for investigating and writing up your findings, Tony.
Is there documentation about the merge/PR workflow for GPII components? Is there documentation about how the Jenkins/Github integration works? Thanks, t On Thu, Jun 21, 2018 at 5:37 AM, Tony Atkins <[email protected]> wrote: > 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). >
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
