Here are the notes from the last meeting:
When: 14.11.22 13:30h Berlin time Where: Jitsi Meet
Previous meeting notes: RIOT CI meeting 10/22 - HackMD
- Finish Murdock Migration
- setup bors
copied from RIOT CI meeting 10/22 - HackMD, updated:
- prepare alternate murdock-worker “ssh” folder & .env settings pointing to “ci-prod.riot-os.org” @kaspar030 => better: prepare second checkout of “RIOT-OS/murdock-worker” (cheap, easy rollback) => set up murdock-worker docker-compose that allows switching, only need to scale up
- get GO from community
on migration day:
let everyone know that we’ll be switching over.
configure web app to not limit all builds
stop all builds
stop ci.riot-os.org builders
scale up ci-prod builders
drop “required status” of old murdock
run some test builds
switch dns to tatooine => asked Oleg
remove note from .murdock.yml: CI: drop obsolete murdock note by kaspar030 · Pull Request #18905 · RIOT-OS/RIOT · GitHub
update links to Murdock badge in the README: README.md: update CI badge by aabadie · Pull Request #18685 · RIOT-OS/RIOT · GitHub
do some test builds
- switch back dns
- roll back worker config
- remove old webhook
- change murdock-worker ssh host to ci.riot-os.org
(added after the meeting as we forgot to write down this explanation) The intended workflow is:
- regular PR commits get built by CI as usual, but doing a quick-build (building only a subset of all boards), unless “CI: full build” is set
- once that passes and the PR is ACKed, instead of merging using the merge button, we use bors to merge by typing “bors merge”.
- bors takes the PR, pushes it to the “testing” branch
- CI does a full build of “testing”
- on success, bors merges testing into master
The main benefits are
- a quickbuild / full build scheme (“regular” PR builds will be <5 minutes, but only fully built branches get merged into master)
- bors does “rollups”, meaning, if multiple PRs are to be “bors merged”, bors merges them together, tests them together and merges them together. That’s more efficient than doing this sequentially, and prevents semantic merge conflicts (e.g., PR a and b pass CI individually, but fail when both merged, breaking master).
Once fully implemented, using bors will be a workflow change (no more “pressing the green button”, but typing “bors merge” instead). But we’ve been using bors for RIOT-OS/riotdocker for a long time now, the experience was good (as opposed to disruptive).
This PR just adds the necessary bors configuration, and once merged will allow using bors to merge PRs using “bors merge”, but the previous workflow is still in place (manual merging can be done, and “regular” PR builds are still full builds).