Stream: committers
Topic: PR builds -- what is happening with the clock?
Josh Mandel (Jan 19 2022 at 22:56):
Taking https://github.com/HL7/fhir/pull/1597 as an examlpe, github shows:
and the Azure Pipelines detail page shows:
@Mark Iantorno do you know what this means? The build seems to have completed (took 25min) but there's a successNotification step with a clock icon... so it seems like the checks aren't fully completed. Do you know what is going on here?
Josh Mandel (Jan 20 2022 at 00:22):
PR builds seem... stuck overall. But maybe just trickling through; I can't tell with the permissions I have.
Mark Iantorno (Jan 21 2022 at 15:08):
Let me take a look
Mark Iantorno (Jan 21 2022 at 15:09):
Seems to have passed now? Maybe there was a stall.
Josh Mandel (Jan 21 2022 at 17:18):
Thanks. Next up @Mark Iantorno in our github branch protection settings we have:
... meaning that branches don't need to be fully up to date before they can be merged. However, the Azure pipeline setup prevents a branch from being merged if it's not up to date. E.g. from https://github.com/HL7/fhir/pull/1604:
This means we're faced with O(N^2) builds to merge N branches, which is especially painful during a "bug bash" like we're hosting this week. Do we want to update the Azure Pipeline so it's consistent with the GH Build protections, meaning that a PR could be merged even if some additional commits have landed in master since the PR branch was last built? Or do we want to just want to manually create PRs with multiple changes lumped together?
Josh Mandel (Jan 21 2022 at 18:26):
Interesting -- looks like a bug in GH. I tried unchecking and rechecking this checkbox, and wound up in a spot where GH does now allow merging of stale (but CI'd) branches:
Josh Mandel (Jan 21 2022 at 18:28):
This leaves open the question of what protections we actually want. Currently the "up to date before merging" requirement is set on master even though it's not set on R4B. I don't know whether that's intentional.
Mark Iantorno (Jan 21 2022 at 19:13):
Ah, R4B was always it's own monster in the way it was set up. I'd prefer to keep the requirement on Master. If there is a lot of work going on with rapid commits, it might be a good idea to create a development branch that everyone works off of, and can quickly iterate on, then once the changes are finalized, it can be merged into master
Last updated: Apr 12 2022 at 19:14 UTC
