Hi, All. I have a meeting scheduled with Gio on Friday to discuss just that. It might be best to postpone the discussion in the arch meeting until next week, we certainly have other stuff to talk about.
Cheers, Tony On 27 June 2018 at 01:54, Tyler Roscoe <[email protected]> wrote: > 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
