CI meeting 11/22

[Kaspar]

Here are the notes from the last meeting:

RIOT CI meeting 11/22

Details

When: 14.11.22 13:30h Berlin time Where: Jitsi Meet

Previous meeting notes: RIOT CI meeting 10/22 - HackMD

Participants

Agenda

• Finish Murdock Migration
• setup bors

Notes

Murdock Migration

• status: copied from RIOT CI meeting 10/22 - HackMD, updated:

  • preparation:

    • …
    • 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

    • rebuild html code with the right base URL (ci.riot-os.org instead of ci-prod.riot-os.org)

    • 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

    • done

  • fallback:

    • switch back dns
    • roll back worker config

  • after migration:

    • remove old webhook
    • change murdock-worker ssh host to ci.riot-os.org

setup bors

(added after the meeting as we forgot to write down this explanation) The intended workflow is:

1. 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
2. once that passes and the PR is ACKed, instead of merging using the merge button, we use bors to merge by typing “bors merge”.
3. bors takes the PR, pushes it to the “testing” branch
4. CI does a full build of “testing”
5. on success, bors merges testing into master

The main benefits are

1. a quickbuild / full build scheme (“regular” PR builds will be <5 minutes, but only fully built branches get merged into master)
2. 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).