chore: verify lockfile on PR, commit on push to main #877
Conversation
|
This might not be correct, I want to verify it actually throws an error if the lockfile is incorrect before merge |
.github/workflows/Lockfile.yml
Outdated
| @@ -1,6 +1,9 @@ | |||
| name: Lockfile | |||
| on: | |||
| pull_request: | |||
There was a problem hiding this comment.
I think we should remove "pull_request" here
There was a problem hiding this comment.
Should we separate it into two workflows, one that commits a new lockfile on push to main, and one that verifies that the PR has a correct lockfile (and could commit a new one to the source branch if the PR is this repo).
We then technically do it twice and the one that runs on pushes to main would be a safety if something would get merged without an updated lockfile.
Or skip validation of the lockfile on PRs and simply update it on every push to main?
There was a problem hiding this comment.
Should we separate it into two workflows
yes, completely, that would be much cleaner. and the modification one would be removed once renovate will be able to update both the pom and the lockfile at the same time.
… indicates the lcokfile is faulty.
…ks-contributors' of github.com:chains-project/maven-lockfile into 875-update-ci-so-that-it-works-for-pr-from-external-forks-contributors
… and pushes to main
… indicates the lcokfile is faulty.
LogFlames
force-pushed
the
875-update-ci-so-that-it-works-for-pr-from-external-forks-contributors
branch
from
89901f7
to
6b88db8
Compare
…ks-contributors' of github.com:chains-project/maven-lockfile into 875-update-ci-so-that-it-works-for-pr-from-external-forks-contributors
LogFlames
deleted the
875-update-ci-so-that-it-works-for-pr-from-external-forks-contributors
branch
No description provided.