utils: fix deprecated initalization of QFD::Permissions
Codecov Report
Merging #2699 (533b631) into main (becdbe0) will increase coverage by
0.00%. The diff coverage isn/a.
@@ Coverage Diff @@
## main #2699 +/- ##
=======================================
Coverage 86.64% 86.65%
=======================================
Files 218 218
Lines 10981 11001 +20
=======================================
+ Hits 9515 9533 +18
- Misses 1466 1468 +2
| Impacted Files | Coverage Δ | |
|---|---|---|
| include/multipass/utils.h | 100.00% <ø> (ø) |
|
| src/simplestreams/simple_streams_manifest.cpp | 94.50% <0.00%> (-2.11%) |
:arrow_down: |
| src/daemon/custom_image_host.cpp | 97.61% <0.00%> (-0.89%) |
:arrow_down: |
| src/client/cli/cmd/launch.cpp | 88.95% <0.00%> (+3.93%) |
:arrow_up: |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
Grr, try again...
bors retry
Try again...
bors retry
bors retry
One more time...
bors retry
Ok, gonna try one last time, then I'm going to merge it manually. I mean it bors, I'll merge it manually if you don't get your act together. I'm warning you!!!!!
bors retry
Running bors to get the merge commit and will manually merge.
bors retry
bors cancel
Canceled.
Running bors to get the merge commit and will manually merge.
IMO that's excessive, it's easy enough to craft that commit yourself, and it doesn't then cheat that bors, indeed, merged it. But if you decide to go for it anyway, you can just push to master, bors will cancel itself. Note that doesn't, on its own, cancel the CI runs that trigger on a push to staging.
IMO that's excessive, it's easy enough to craft that commit yourself, and it doesn't then cheat that bors, indeed, merged it.
Ok, that's fair.
...you can just push to ~
master~main, bors will cancel itself.
When I did push to main, bors kept running until I explicitly told bors to cancel. Perhaps it takes a while for the manually merge to be noticed?
Note that doesn't, on its own, cancel the CI runs that trigger on a push to
staging.
Right. I went to the running Workflows and tried multiple times to cancel, but I don't think Github Actions honors the cancel all of the time.
When I did push to
main,borskept running until I explicitly toldborsto cancel. Perhaps it takes a while for the manually merge to be noticed?
Hmm. Maybe. Or maybe it notices HEAD changes, but not base? (at least not until it fails to push).
Right. I went to the running Workflows and tried multiple times to cancel, but I don't think Github Actions honors the cancel all of the time.
The problem is the if: bit in steps. If it says always() (as it needs to, if you want it to run despite skipping previous a step), that step won't be cancelled… I tried to fix all the cases to have always() && !cancelled(), but may have missed some - and I'm not clear on whether that would mean it does get cancelled…
You would think if someone wants to cancel a workflow run, they just want it to stop period (like kill -9 the whole thing) and not care about subsequent steps :shrug:
You would think if someone wants to cancel a workflow run, they just want it to stop period (like
kill -9the whole thing) and not care about subsequent steps shrug
Well, that allows you to do cleanup. Like in the Testflinger case, that gives me a chance to cancel running jobs
But what is crazy, is the implicit if: success(), which only gets overridden if you have always() in your condition. Otherwise it just gets app&&ed…