Hi, Quick update: Jürg thankfully notified me that the test import of the issues was generating a lot of notification spam, because GitHub sends one notification per `@` mention. Apologies if you've been spammed. I have stopped this test import for now. I think we can already see from the 10% or so imported issues how they're going to look like.
We will still end up generating this notification spam when we actually do migrate, but that will be a one-time thing. So, we can tell folks to brace themselves before that happens. - Chandan On Thu, Aug 13, 2020 at 1:24 PM 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. > > * This is still early days for GitHub Actions, and that shows mostly > in the UX area. I've seen their live logs start and stop at random > places. Sometimes errors are only visible in the "raw logs" and not > the pretty logs. I expect this to get better with time. However, the > worst issue I noticed was that sometimes test jobs can stop halfway > through without any warnings or errors. And the job is marked with the > success status. It's on my to-do list to report this issue through > proper channels (once I find out what those are). > > * 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 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. > > > Besides code and CI, we will also need to migrate issues and > > documentation. I think it's important to migrate issues at the same > > time as code/PRs to properly handle issue references/links. There is a > > `node-gitlab-2-github` project [1], which may be helpful, however, I'm > > not familiar with it myself. > > Jürg, I definitely agree. I just tried on node-gitlab-2-github my test > BuildStream repo and it seems to work for the most part. It is still > chugging along on my machine, and hasn't finished a full run yet. But, > you can still see the results at: > https://github.com/cs-shadow/buildstream/issues. > > There's an obvious catch here - all issues seem to have been created > by my user. This is expected because it only has my access token so it > can only do operations as my user. It hasn't got to merge requests > yet, but I expect they'd also be created as my user. Having said that, > it does add one line at the top of each comment, with details about > the original author and time. For example, "In GitLab by @tristanvb on > Apr 28, 2017, 08:54". > > 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. > > Cheers, > Chandan
