opendownstream-pr workflow should close buildah PRs once the PR here merges

[Luap99]

I fear we are cluttering the downstream repos with PRs that nobody closes and/or makes it harder for maintainers there to work through the actual PRs that matter. So the workflow should close the downstream PR once the PR here is merged to avoid them lingering around and require manual closing.

[Luap99]

@flouthoc PTAL

[mtrmac]

Do we want to do that only when the downstream PRs succeed (or, harder, fail only in a way that looks like a flake)?

Otherwise, I worry that we end up with a bot that files PRs, closes PRs, and eventually everyone will just be filtering them out out of inboxes and filters and statistics.

[flouthoc]

I thought it is responsibility of the maintainer who merges PR in container-libs to close downstream PR if there are any.

[mtrmac]

Hum, that might have surfaced a difference in assumptions.

I understood the discussion in #305 to mean that the downstream PRs are ultimately the responsibility of the downstream project to react to / raise an alarm on a failure, and ~managed (in some unknown-to-me way) by the downstream PR reviewers.

Rereading that, it might have been the intention that container-libs reviewers will manually verify every downstream PR before merging in container-libs. That… sounds tedious, I’d much rather have it as an explicit blocking check (as alluded to, and rejected, in #305 (comment) ).

[Luap99]

My assumption is the container-libs reviewer looks at these PRs, but then again there is no enforcement. With the reviews on the downstream repos I doubt people pay much attention for this otherwise. My point was to have this serve as soft gating that is enforced manually.

I don't see how we can have a mandatory job that blocks merges here as we sometimes break downstream intentionally which then requires another PR downstream to adapt for these breakages.

[mtrmac]

There’s the test_skopeo precedent. It’s workable enough in practice, but, also, definitely not painless — it’s the slowest and most flaky test job.

[flouthoc]

My assumption is the container-libs reviewer looks at these PRs

This is my thought too that container-libs reviewers are the one who are looking at these PR. I have no opinion on making this as part of enforcement in CI or not, maybe we will more clear picture after some time once this is used enough ?

Making change to close downstream PR when upstream PR is merged is a good idea and can be implemented as well.

[Luap99]

There’s the test_skopeo precedent. It’s workable enough in practice, but, also, definitely not painless — it’s the slowest and most flaky test job.

Well the thing is that is really not workable in practise when you look at a big repo like buildah or podman. Duplicating so many cirrus.yml lines is simply a non starter to me. And even then I have seen several CI issues because the CI image updates where not carried out in sync between the repos causing the test to break in the other repo.

I guess there is some interesting possibilities by using Starlark https://cirrus-ci.org/guide/programming-tasks/. Then we could fetch the right cirrus.yml from another repo and create the jobs as part of this repo like any other cirrus task here. I never had the time to look into starlark to see if this is actually workable.

Overall I am not sure on the ROI on any of these efforts even with the current open PR workflow. The extra work of checking this is likely not less than the few times where something actually broke.
Long term there are the plan to have all repos in a monorepo and then such issue would go away so I am reluctant to spend much time on these things.

[mtrmac]

… that is really not workable … Duplicating so many cirrus.yml lines

Good point.