-
Notifications
You must be signed in to change notification settings - Fork 701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add validate-revision workflow #9561
Conversation
# It's almost exact copy of validate.yml and has to be maintainted in concert with it. | ||
# The difference is in the `on` attribute and the step where we do >> cabal.project.validate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we then have an “☞ N.B. If you modify this, incorporate the same modifications in validate-revision.yml
!” in validate.yml
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point. I'm thinking now if there may be a way to reuse the existing workflow, so that we avoid duplication altogether. I'll keep you posted!
I should have mentioned: I tried it on my own fork, and it works as expected: https://github.com/ulysses4ever/cabal/actions/workflows/validate-revision.yml But I really don't like the duplication and looking into it... |
b187832
to
8e31729
Compare
@ulysses4ever Looks to me like you found something appropriate to avoid duplication! |
@Kleidukos i haven’t found a way to properly plumb it together yet. |
Regardless of the duplication, great job! Let's make sure to document it properly in many places, so that it gets used. |
ca9325f
to
50bbf61
Compare
Dear all, I revamped the initial submission to:
Please double-check. It's impossible to test it before merging per se, but I checked that it seems to be doing the right thing on my fork. Here's a run for |
It can be started manually to check that certain version bumps build fine. It will ask to input an allow-newer line and a constraint line, which it will add to the cabal.project file. For example: the "filepath" allow-newer line and "filepath == 1.5" constraints line will make sure that the build plan will have `filepath` at version 1.5.
The GitHub workflo defined here can be started manually to check that certain version bumps build fine. It will ask to input an allow-newer line and a constraint line, which it will add to the
cabal.project
file. For example: the "filepath" allow-newer line and "filepath == 1.5" constraints line will make sure that the build plan will havefilepath
at version 1.5.Unfortunately, it's almost an exact copy of validate.yml and has to be maintained in concert with it.
/cc @Mikolaj who pushed the revisions policy, see #9531 (comment)
Template Β: This PR does not modify
cabal
behaviour (documentation, tests, refactoring, etc.)Include the following checklist in your PR: