-
Notifications
You must be signed in to change notification settings - Fork 691
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 a --dry-run build check of cabal.project.release #9610
Merged
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This is very minor now but still:
HEAD
is the default value for--index-state
(see the docs). We don't have a convention of explicitly reinforcing defaults in these workflows, I believe. So, doing it in one place looks confusing. What do you think?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.
That one I put there intentionally to override the
--index-state
from the project.cabal/cabal.project.release
Line 8 in 833a17d
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.
For CI we want to test with
HEAD
and bump the timestamp in the project when cutting a release, wouldn't we?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.
I see... This is maybe a matter of preference but I think if you want to test cabal.project.release, it seems strange to override anything in it. But I can see someone arguing that testing the release config against the current Hackage state may be worthy.
At the very least, please, add a comment there why this index-state flag is needed.
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.
@Mikolaj in making a release should we be making mention of
cabal.project.release
and when to set itsindex-state
? Do you think testing withHEAD
but fixingindex-state
at release is the right way to go?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.
The index-state that is used to build releases can afford to be more conservative. The only constraint on the process is, presumably, that others can verifiably build their own version of the release using precisely the same dependency versions (if they so desire).
Stepping back a second, @Mikolaj I think you understood what I wrote perfectly and I find no fault in your analysis. In particular, I agree you do want to test Cabal against the latest Haskell universe, so you get a heads up of problems with newer dependencies.
Dealing with such breakage during regular pull request CI is a suboptimal time, but I agree it's better than "never". Dealing with it at the start of the release process, however, seems unnecessary. The index-state should be fixed for a release, and whether or not it's fixed at the beginning of the release, or immediately after the previous release, makes little difference to the release in the long run. Doing it after, however, means fixing breakage is not the release manager's responsibility. And there would be plenty of time to get the build working again should anything break.
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.
After a thought, I agree, bumping the index after a release is best, since it makes the already exhausting release process lighter. I've added the point to our release checklist. The counter-argument is that our releases often sync with a new GHC and we want to know if the toolchain builds with all the new versions of libraries prepared for the GHC just released on Hackage. However, our CI is almost never updated to include the new GHC (pre-alpha; so we'd need head.hackage for that) in time for the release, because too many problems emerge (so syncing with a GHC is partially decoupled with the release proper, with its own ticket for tracking the tasks, e.g., see #9729). So it's impossible to early test in CI all the new versions of packages, because we can't even test the new base. So the conservative index is just fine.
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.
@Mikolaj and @chreekat, are we going to enable tests in
cabal.project.release
?cabal/cabal.project.release
Line 5 in 46e8221
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.
I think @chreekat wants to do that on gitlab CI eventually. Given that our GHA CI takes very long already, maybe it's too much [edit: to enable on GHA] until we are ready to review our CI and trim down some other non-essential or near-duplicate jobs.
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.
I'm not so sure any more. We've just had a serious release issue due to that policy. Let's move the discussion to #9819.