-
Notifications
You must be signed in to change notification settings - Fork 346
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
Setup automated releases from GitHub Actions CI #867
Conversation
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 super nice! 🎉 I guess this just speeds up the process of moving completely to GHA as we did in chill.
Now @posco just needs to add a few secrets to the repo! 🚀 (I don't have enough perms)
I just received admin access for this repo and configured the Sonatype+PGP secrets. It may take several attempts after this is merged to validate that everything is working as expected.
Yes, I think it would be a nice followup PR to move all the CI to GitHub Actions. |
I'm planning to followup with similar changes in the chill and bijection repos. |
Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see htts://github.com/olafurpg/sbt-ci-release
c32e889
to
2d33301
Compare
Codecov Report
@@ Coverage Diff @@
## develop #867 +/- ##
===========================================
- Coverage 89.32% 89.27% -0.05%
===========================================
Files 117 117
Lines 9326 9326
Branches 365 365
===========================================
- Hits 8330 8326 -4
- Misses 996 1000 +4
Continue to review full report at Codecov.
|
@@ -1 +0,0 @@ | |||
version in ThisBuild := "0.13.8-SNAPSHOT" |
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 changes the local value of version
to be formatted like this 0.13.7+34-2d333018-SNAPSHOT. Is that an acceptable change? I think it's possible to get configure the version to not include the git describe information you prefer to keep the old behavior.
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.
imo i think it's ok.
Yeah following up with a PR would be nice... I've been meaning to do this for a long time lol |
runs-on: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v1 | ||
- uses: olafurpg/setup-scala@v7 |
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.
One i thing i realised is that we can add some artifact cache here
- name: cache SBT
uses: coursier/cache-action@v3
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 job only runs the releases, which I think is desirable to run with a clean machine. My experience is that GitHub Actions is usually fast enough for most projects without caching
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.
right, anecdotally I've seen it fail a few times ¯_(ツ)_/¯ I guess we can always re-trigger?
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.
You can always rerun the job or force push the git tag
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.
right that's what I meant. I understand that this is probably a preference thing but i don't feel that fetching artifacts every time offer a lot of guarantees. If a build is green on develop
for a given hash, running the release job (develop
or tag
) should mean that it will equally build and not be subjective to transient errors. Publishing to sonatype should be the only thing that can fail (which fails quite often unfortunately)
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 great and super exciting!
One thing we probably want to address: the CI is a bit flaky on two kinds of tests: 1. approximate laws related to floating point numbers, 2. tests checking probabilistic bounds (this is true with Prob > y, which we run many trials and see if the result is highly improbable given that).
We should probably tune it so that those rarely happen.
Merging to see what happens on master. Small heads up, it usually takes a few failed attempts before it works correctly |
The SNAPSHOT release worked, you can download the artifacts with
The next step is to try a stable release by pushing a git tag. Any objections if I push a v0.13.8-M1 tag to see if everything works? FWIW, I have a
I normally cut releases by running |
The CI release currently runs the publish step without testing so flaky failures should not block the release. It's possible to add custom steps before |
Let's include #850 as well |
One argument is the honors should go to @olafurpg who once again did the important work of making releases easier, and helping remove friction from the ecosystem. My second nomination would be @regadas who has really stepped up to do a lot of work managing these libraries. For the first time you will be able to release since you don't need the twitter sonatype credentials. I'm happy to do it as well... :) |
I pushed a tag for v0.13.8-M1 and it seems to have worked
I opened #871 to make it easier to write release notes. I'll follow up with similar changes in the chill and bijection repos, although it may take a few days until I get around to it. |
it worked! 🎉 however i thought you were releasing |
@johnynek thx for the acknowledgement 🙏 |
You can do the non-milestone release, I just wanted to validate the pipeline was working :) |
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Follow up to twitter/algebird#867 Previously, releases were done from a local computer with the sbt-release plugin. Now, releases happen automatically from GitHub Actions. Every merge into master should trigger a SNAPSHOT release and every git tag push should trigger a stable Sonatype release. For more details, see olafurpg/sbt-ci-release
Previously, releases were done from a local computer with the
sbt-release plugin. Now, releases happen automatically from GitHub
Actions. Every merge into master should trigger a SNAPSHOT release
and every git tag push should trigger a stable Sonatype release.
For more details, see https://github.com/olafurpg/sbt-ci-release