Skip to content
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

Merged
merged 1 commit into from
Sep 22, 2020

Conversation

olafurpg
Copy link
Collaborator

@olafurpg olafurpg commented Sep 18, 2020

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

@olafurpg olafurpg requested a review from johnynek September 18, 2020 08:58
Copy link
Collaborator

@regadas regadas left a 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)

@olafurpg
Copy link
Collaborator Author

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.

I guess this just speeds up the process of moving completely to GHA as we did in chill.

Yes, I think it would be a nice followup PR to move all the CI to GitHub Actions.

@olafurpg
Copy link
Collaborator Author

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
@codecov-commenter
Copy link

codecov-commenter commented Sep 18, 2020

Codecov Report

Merging #867 into develop will decrease coverage by 0.04%.
The diff coverage is n/a.

Impacted file tree graph

@@             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     
Impacted Files Coverage Δ
...in/scala/com/twitter/algebird/scalacheck/Gen.scala 95.34% <0.00%> (-4.66%) ⬇️
.../main/scala/com/twitter/algebird/Successible.scala 87.50% <0.00%> (-4.17%) ⬇️
...src/main/scala/com/twitter/algebird/Interval.scala 80.00% <0.00%> (-0.87%) ⬇️
.../main/scala/com/twitter/algebird/BloomFilter.scala 94.24% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fdd3aba...2d33301. Read the comment docs.

@@ -1 +0,0 @@
version in ThisBuild := "0.13.8-SNAPSHOT"
Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

@regadas
Copy link
Collaborator

regadas commented Sep 18, 2020

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
Copy link
Collaborator

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

Copy link
Collaborator Author

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

Copy link
Collaborator

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?

Copy link
Collaborator Author

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

Copy link
Collaborator

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)

Copy link
Collaborator

@johnynek johnynek left a 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.

@olafurpg
Copy link
Collaborator Author

Merging to see what happens on master. Small heads up, it usually takes a few failed attempts before it works correctly

@olafurpg olafurpg merged commit fd6454a into twitter:develop Sep 22, 2020
@olafurpg olafurpg deleted the ci-release branch September 22, 2020 10:58
@olafurpg
Copy link
Collaborator Author

The SNAPSHOT release worked, you can download the artifacts with

cs fetch com.twitter:algebird-core_2.11:0.13.7+37-fd6454ad-SNAPSHOT -r sonatype:snapshots

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 git-release script in my $PATH

❯ cat `which git-release`
set -eux
version=$1
git tag -af "v$version" -m "v$version" && git push -f origin v$version

I normally cut releases by running git release 0.13.8 from the terminal. I usually wait until the CI release job has completed before publishing a release on GitHub.

@olafurpg
Copy link
Collaborator Author

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).

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 +publishSigned in case you prefer that, but when I tried this in the past I normally ended up spending more time dealing with incomplete releases than catching actual bugs before a release (the master branch has presumably gone through PR code review).

@regadas
Copy link
Collaborator

regadas commented Sep 22, 2020

v0.13.8-M1

we can go with a v0.13.8 since there are dependency updates, #844, #829 and some other minor things.

It's possible to add custom steps before +publishSigned

Yeah we can always just add sbt +test if needed but +1 on leaving it as is for now.

@regadas
Copy link
Collaborator

regadas commented Sep 22, 2020

Let's include #850 as well

@regadas
Copy link
Collaborator

regadas commented Sep 23, 2020

I think we are good for a new release v0.13.8.

who should do the honours? I can prepare the release notes if you want /cc @johnynek @olafurpg

@johnynek
Copy link
Collaborator

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... :)

@olafurpg
Copy link
Collaborator Author

I pushed a tag for v0.13.8-M1 and it seems to have worked

❯ cs resolve com.twitter:algebird-core_2.12:0.13.8-M1
com.googlecode.javaewah:JavaEWAH:1.1.7:default
com.twitter:algebird-core_2.12:0.13.8-M1:default
org.scala-lang:scala-library:2.12.12:default
org.scala-lang:scala-reflect:2.12.12:default
org.scala-lang.modules:scala-collection-compat_2.12:2.2.0:default
org.typelevel:algebra_2.12:2.0.0:default
org.typelevel:cats-kernel_2.12:2.0.0:default

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.

@regadas
Copy link
Collaborator

regadas commented Sep 25, 2020

it worked! 🎉 however i thought you were releasing v0.13.8

@regadas
Copy link
Collaborator

regadas commented Sep 25, 2020

@johnynek thx for the acknowledgement 🙏

@olafurpg
Copy link
Collaborator Author

You can do the non-milestone release, I just wanted to validate the pipeline was working :)

olafurpg pushed a commit to olafurpg/chill that referenced this pull request Dec 2, 2020
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
olafurpg pushed a commit to olafurpg/chill that referenced this pull request Dec 2, 2020
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
olafurpg pushed a commit to olafurpg/bijection that referenced this pull request Dec 2, 2020
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
olafurpg pushed a commit to olafurpg/bijection that referenced this pull request Dec 2, 2020
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
olafurpg pushed a commit to olafurpg/chill that referenced this pull request Dec 2, 2020
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
olafurpg pushed a commit to olafurpg/bijection that referenced this pull request Dec 2, 2020
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
@olafurpg
Copy link
Collaborator Author

olafurpg commented Dec 2, 2020

regadas pushed a commit to twitter/chill that referenced this pull request Dec 2, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants