.github: add workflow to open downstream PR #305
Conversation
flouthoc
force-pushed
the
downstream-PR
branch
4 times, most recently
from
5151cac to
6f01976
Compare
Signed-off-by: flouthoc <flouthoc.git@gmail.com>
flouthoc
force-pushed
the
downstream-PR
branch
from
6f01976 to
2a95105
Compare
There was a problem hiding this comment.
I don’t understand; what is the goal of this?
With the go mod edit -replaced, I read this to mean that none of these PRs should ever be merged. So why are they PRs?
Guessing, is this intended to test container-libs in context of Buildah, but in a way that does not block merging any changes in container-libs?
| cat go.mod | ||
|
|
||
| # Update the go.mod file to use the specific commit | ||
| go mod edit -replace go.podman.io/common=github.com/containers/container-libs/common@${COMMIT_SHA} |
There was a problem hiding this comment.
There are 3 Go modules in this repo
| if [ "${{ env.PR_ACTION }}" = "created" ]; then | ||
| COMMENT_BODY="✅ A new PR has been created in buildah to vendor these changes: **${{ env.TARGET_REPO_PR_URL }}**" | ||
| else | ||
| COMMENT_BODY="✅ The existing PR in buildah has been updated with these changes: **${{ env.TARGET_REPO_PR_URL }}**" |
There was a problem hiding this comment.
Is this going to add the same comment on every force-push? That might be rather annoying. Can this edit a pre-existing comment, or use some other way to convey that state? (a test status???)
|
@mtrmac This PR is not ready for review yet. I will undraft it when it's ready. |
The goal is to open a PR in buildah/podman automatically to run there tests there to see if that passesCI there. This is done as it seems like the simplest solution compared to trying to run the buildah/podman tests here (like done with skopeo) since that would require a ton of cirrus.yml duplication. The goal is simply to catch regressions before me merge the PRs here. Now it makes sense to define some sort of criteria when to open a PR over there, first of all it should only happen when .go files are changed but I guess for many trivial changes we might still want to save the time? |
Ah, OK. If the depending projects are fine with the ongoing flow of PRs, filing PRs certainly works and it is easier to set up. |
No description provided.