Conversation
This will look for a branch called `v3-labthings-branch` and fall back to `v3-labthings-main` then `v3` if it doesn't exist. I've added a line to print the branch that's actually checked out.
This should tidy up the "checks" tab in merge requests.
Barecheck - Code coverage reportTotal: 96.34%Your code coverage diff: 0.00% ▴ ✅ All code changes are covered |
|
The publish workflow ran correctly when I made a https://github.com/labthings/labthings-fastapi/actions/runs/23465657129 |
rwb27
force-pushed
the
ci-improvements
branch
11 times, most recently
from
36e053e to
bf80af4
Compare
It's now possible to add a line to the PR description that starts with "OFM Feature Branch:". This specifies a feature branch to test against. There's some CI logic to: * Run the job only if a matching line is present * Extract the matching line from the PR description * Check out the relevant branch.
|
I have checked manually that
I have force-pushed over these commits to keep things tidy, and because the PR description isn't actually part of the commit so it would all look a bit ambiguous anyway. I would welcome feedback on my CI syntax and my bash script. There was quite some trial and error to handle the multiline string of the PR body properly, but I think the solution I've arrived at is reasonable. |
Co-authored-by: Beth <167304066+bprobert97@users.noreply.github.com>
rwb27
force-pushed
the
ci-improvements
branch
4 times, most recently
from
256d946 to
ade0858
Compare
rwb27
force-pushed
the
ci-improvements
branch
4 times, most recently
from
18bbb3b to
e7d6ab7
Compare
This uses YAML anchors to reduce duplication, and switches to relative paths for the working directories. GitHub Workflows don't offer a way to merge YAML arrays, so I've needed to split the feature branch job so that it determines the name of the feature branch in a separate job. I spent a while playing with a custom action to deduplicate the steps, but it doesn't work as nicely. I also removed some unnecessary curly braces.
|
@bprobert97 I think this is ready for rereview. I've made a few improvements:
|
bprobert97
left a comment
bprobert97
left a comment
There was a problem hiding this comment.
Happy with the YAML updates. Just want to check if this has been tested before I click approve
yes, I've tested it both with and without a linked branch. If you look in "checks" you should see the final commit here has been tested against both branches v3 and choose_int_downsample. If you expand the "check out OFM" step, it shows the right branch was used. I've also tested that it doesn't run if no branch is specified, with the relevant jobs showing as "skipped" rather than failed. |
2 participants
This tidies up a couple of things in CI:
test-against-ofmjob is duplicated:test-against-ofm-v3always runs and will test every PR againstopenflexure-microscope-server/v3to ensure compatibility.test-against-ofm-feature-branchwill run only if there's a line in the PR body starting withOFM Feature Branch:specifying a branch to test against. This allows optional features to be tested, by creating an OFM branch that enables them.I think this gets us the best of both worlds. Assuming the new feature logic I've outlined in #294 is reasonable, this PR makes all the CI changes that are required.
This PR also reduces the need to merge PRs when jobs have failed.
test-against-ofm-v3is still allowed to fail, but if we stick to #294 then merging when that job fails should very much be the exception.OFM Feature Branch: choose_int_downsample