"Actions"

[kousu]

Gitea 1.20 will have a CI system inspired by Github Actions: go-gitea/gitea#13539 (merged behind a feature flag in 1.19: go-gitea/gitea#21937)

I haven't reviewed it at all yet, I just want to tag this so that we investigate at some point if we should be rewriting bids-hook to use this instead.

[mguaypaq]

That would be great! Writing code is fun, but getting rid of it in favour of a simpler solution is even better.

[kousu]

Status:

• https://docs.gitea.com/1.19/usage/actions/overview is 404

• https://docs.gitea.com/1.20/usage/actions/overview is 200 but claims Actions exist "since 1.19", which is a fudge; spineimage.ca is currently running 1.19.0 and https://spineimage.ca/admin/runners is 404 EDIT: because it's behind a feature flag that I haven't turned on, obviously.

• But we have https://github.com/neuropoly/gitea/releases/tag/v1.20.0-rc2-git-annex built and published; that should support Actions; I'd say 1.20 will probably be out this month.

• To use it, we must deploy act_runner (which equivalent to deploying Drone, but maybe less invasive: it doesn't have a UI of its own like Drone does and it is happy to run using rootless docker, unlike Drone which recommended using a separate server).

• Deployment looks relatively simple:

  1. We run (on a dev machine) ./act_runner generate-config > config.yaml; we can save config.yaml as an ansible template file
  2. During deployment we get a runner token, hopefully from the API (TODO: check if this exists in the API yet)
  3. Set up rootless docker (TODO: check if podman works :3)
  4. Set up a .service file to run act_runner (TODO: we can probably improve on the way they did their example .service file)

[kousu]

All said, I still like bids-hook. I don't think we should give up on it yet.

In the Drone-based version I ran into a lot of pain points:

• we need to include the test scripts in the repos, which means there's no way to update the tests globally; for most dev teams that's a feature because the dev team wants to be involved in knowing when their tests might break, but for a dataset server I'd propose that's a bug
• the test scripts are in the repos(!), so that's risky remote code execution(!)
• we either need to build/install git-annex and bids-validator as part of the test script -- which easily eats up 90% of the test -- or pre-build a container with them installed, either locally on the test server or on a separate server and then push to docker.io? How and when and where do we handle rebuilding that container to get security updates?
  • with bids-hook, we install nodejs with apt, and bids-validator with npm, and updates happen with unattended-upgrades and all that's already working. more or less.
• containers, being ephemeral, need to download the dataset each time, which means
  • we need to worry about permissions and tokens; I did manage to get this working with Drone but it was pretty fragile
  • we can't take advantage of the speed/space savings of git clone --shared or git config annex.hardlink true, which, for multigigabyte datasets, could easily creep up on us