On Thu, Aug 13, 2020 at 8:25 AM Chandan Singh <[email protected]> wrote:
> Hi all, > > Since I have toyed with GitHub actions a bit, here are my notes and > thoughts on that topic: > > * So far, I've managed to get all our tests working with GitHub > Actions. You can find the configuration at: > > https://github.com/cs-shadow/buildstream/blob/master/.github/workflows/ci.yml > . > Everything that I haven't ported is mostly because I haven't had time > to do that yet. I don't see any big missing features that'd prevent us > from adopting Actions. They do support persisting artifacts, scheduled > jobs etc so I think we are covered. > > You will also find more of my notes and rants in the above mentioned > ci.yml file. > First off, thanks for doing this work! I'm flabbergasted that GitHub Actions lets you run a priv'd container on their Azure builders. =) (I'm guessing that each builder must be in its own isolated VM then.) * Since we will have a public repository, we qualify for "free" and > "unlimited" actions. I am sure both those terms come with associated > fineprint. So far, it seems like Actions could cope up with ~4-5 > pipelines in parallel (each with 7-8 jobs). I am not sure whether the > free tier will be able to keep up with our load once we start getting > real patches on GitHub. If not, we may need to add some custom runners > (similar to what we have on GitLab). > In chatting with the ASF infra team, we have a pretty clear runway to use as much GitHub Actions as we need. So, my recommendation is to set up whatever we think is best...if we run into limits, we'll sort it out then with our GitHub contacts. * In terms of performance, I noticed that even these free runners do > better than our GitLab runners. When things are going well, running > the full testsuite takes ~15 mins on GitHub vs ~25 mins on GitLab. > Awesome. > Unfortunately this tool doesn't remap issue/merge request references > (as mentioned in their README). So, references to issues (like #42) > and merge requests (like !42) are not remapped to their new numbers. > > This is something that _could_ be automated if we want to spend some > time writing a patch for node-gitlab-2-github. > As much as the perfectionist in me would love a full remapping, I doubt that there's value here. (We could keep the GitLab repos/issues alive in a locked-down state as well...) Cheers. -- justin
