As many have probably noticed, there is an in-progress migration to GitLab-CI for VTK. You can see CI jobs at the top of your Merge Request in the “Pipelines” tab. There are still a few builds that have not migrated and are still on buildbot.
Do: test currently talks to just buildbot because there’s no other way to do it. It can talk to CI and buildbot, but the syntax for doing anything more than “test everything” is complicated just going to be confusing during the transition. So until then, it talks to just buildbot. Developers and Maintainers in the VTK project can start jobs on their own from the pipeline tab. There are some exceptions:
Contributors who are not at least Developers have jobs in their fork; maintainers generally don’t have access to start jobs for them (ping me and I can start them using some sysadmin-like magic)
Those same contributors cannot start jobs after a Do: reformat because the robot (which does the push) does have permission, so the jobs appear in the vtk/vtk repository. Contributors cannot start these, but Developers and Maintainers can.
See this issue for tracking the remaining migration tasks. Once CI is the only thing testing VTK, contributor documentation will be updated and Do: test will start talking to GitLab-CI instead of buildbot.
Thanks for all the work you’ve put into this, Ben. After learning to use the new system, I’ve found it to be much nicer than the old one.
Since jobs can be started from the “pipeline” page, is there a need for Do: test? The only issue I see is that it’s hard for a pure-text documentation to describe exactly where to find the buttons.
Yes, the two cases in the first post do not have the buttons available. The robot is special (read: lots of permissions everywhere) and can hit the button for folks via Do: test.
Is it not possible to have the robot push the clang reformatted MR back to the source repository, so that test jobs can still be started by contributors?
The robot does push to the source repository. The thing is that where the pipeline is created depends on the access of the user pushing the code. The robot can either have access to all repos (and make pipelines in the target repo) or the robot…well, it wouldn’t work (because it also couldn’t do merges because it wouldn’t have access to the target repository).
I’m confused. If the robot pushes the code back to the forked repository then why are the tests able to be run from that repository before the reformat but not after? Couldn’t the robot inherit access to the forked repository for merges from the pull requests?
Alternatively can the pipelines in the vtk repository be created with user permissions from the forked repo?
Not for pushes. I can have the robot sudo for API access, but pushes are over SSH and only the robot has its SSH key registered (and I’m not generating an SSH key per user either).
Alas, it’s not how the GitLab feature in question works.
I’m currently working on the last few machines from buildbot in this MR. Once that lands, Do: test can start talking to GitLab-CI and can be used to start jobs when the “Play” button is not available already.