-
-
Notifications
You must be signed in to change notification settings - Fork 369
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
Semiautomatic hackage releases #2163
Conversation
dont worry, the diagnostic is the "hard" part, will add the bound here, thanks! |
cd $(ls -d ./incoming/${{ matrix.package }}-*) | ||
echo "packages: . ../../* ../../plugins/*" > cabal.project | ||
# TODO: remove when not needed | ||
echo "allow-newer: Chart-diagrams:diagrams-core, SVGFonts:diagrams-core" >> cabal.project |
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.
These are only needed to build the benchmark suite of ghcide. The benchmark suite is not a requirement for uploading to Hackage imho, and should be skipped
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.
ya, but to use a simple autogenerated cabal.project with packages: . ../../* ../../plugins/*
cabal has to find a build plan for shake-bench. The alternative is a cabal project listing explicitly all packages but shake-bench.
Otoh in theory you should be able to run the benchmarks (like tests) with the hackage version too, and ideally those allow-newer should be removed to allow it
if: steps.get-hackage-version.exists != 'true' | ||
run: | | ||
cd $(ls -d ./incoming/${{ matrix.package }}-*) | ||
cabal build --enable-tests --enable-benchmarks |
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.
cabal build --enable-tests --enable-benchmarks | |
cabal build --enable-tests |
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.
ideally benchmarks should be able to run using the hackage version
981dede
to
b50be26
Compare
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.
Nice job, this is going to be super useful
Next step would be integrating @kowainik Policeman to validate the updated version numbers: https://kowainik.github.io/projects/policeman |
wow, i had forgotten it, it would be really nice, will open an issue after merging this |
I've used a hackage token generated from my account, it can be changed in the project secrets
Most of them have @pepeiborra as unique maitainer so an option could be that @pepeiborra generates a hackage api key (i would create a new, dedicated, one). But even doing that i would add some more maintainers to those plugin with only one parent 😉 EDIT: resolved with a new token with full access, thanks @pepeiborra! |
I have added you to the maintainers list for all of them |
Ok the workflow has failed in the last step, cause i did not put the hackage api key: https://github.com/jneira/haskell-language-server/actions/runs/1208936609
I think the deinitive test can be done with the next release |
97629f4
to
1fd80c4
Compare
It would be nice to back port this to the 1.3.0-hackage branch and use it for the Hackage upload |
I was waiting for the automatic backport, but CI is quite slow lately, will backport manually |
backported with 97003e2 |
As the workflow will take ages to start i've started it in my repo: https://github.com/jneira/haskell-language-server/runs/3545669772 |
It is failing for hls-call-hierarchy-plugin: