Change release GH actions to create and release from release branch #326
Conversation
|
Current dependencies on/for this PR: This stack of pull requests is managed by Graphite. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #326 +/- ##
==========================================
+ Coverage 77.34% 77.38% +0.04%
==========================================
Files 336 336
Lines 9990 9986 -4
Branches 1462 1464 +2
==========================================
+ Hits 7727 7728 +1
+ Misses 1680 1675 -5
Partials 583 583 |
| git push | ||
| ./gradlew clean publishReleasePublicationToSonatype closeSonatypeStagingRepository -Dorg.gradle.parallel=false --stacktrace | ||
|
|
||
| - name: Set next SDK version |
There was a problem hiding this comment.
we shouldn't be setting the next version in pre-release-workflow. At least that's how I thought it.
pre-release-workflow will:
- create the staging repository in nexus
- upload the artefacts to it
- close repositories
at this stage, we are able to perform smoke testing. That is why it's called pre-release.
It is important that we do not update gradle.properties with next-version-SNAPSHOT in this step, because we need the actual "pre-released" version for the next workflow (release.yaml)
In release workflow we will:
- find the already created staging repository (this is why we don't need to update gradle.properties in previous step)
- make the actual release from sonatype to maven central
does it make sense? i wasn't able to test the full flow, but it should be working.
If so, we should make the same changes to swazzler
There was a problem hiding this comment.
So all the changes should be done to the release branch at release/version, so the release stage should be referring to that and not master.
The goal here is to take a snapshot of master and move it to another branch so that master can move along, assuming that everything after that goes into master is part of the next release.
If there is something wrong in the release branch, we can fix it in master, and cherrypick the change and generate and test another release candidate. As long as we can do that in the release branch without needing to increment the patch version, we should be good.
| uses: actions/checkout@v3 | ||
| with: | ||
| run: | | ||
| git checkout -b release/${{ github.event.inputs.version_to_release }} |
There was a problem hiding this comment.
@cesarmax22 this is where I'm creating the release branch and at that point, everything should be running on that and not modifying master.
There was a problem hiding this comment.
I need to change this so the branch name doesn't have the patch version - will update in a bit after we talk this through.
| @@ -83,12 +88,20 @@ jobs: | |||
|
|
|||
| - name: Gradlew Pre-Release | |||
| run: | | |||
| sed -i -r "s#version = ([^\']+)#version = ${{ github.event.inputs.current_version }}#" gradle.properties | |||
| sed -i -r "s#version = ([^\']+)#version = ${{ github.event.inputs.version_to_release }}#" gradle.properties | |||
There was a problem hiding this comment.
This is done on release/<version>
| @@ -100,7 +113,7 @@ jobs: | |||
| - name: Swazzler Release | |||
| run: | | |||
| cd ./embrace-swazzler3 | |||
| ./gradlew clean release -Dorg.gradle.parallel=false -Prelease.useAutomaticVersion=true -Prelease.releaseVersion=${{ github.event.inputs.current_version }} -Prelease.newVersion=${{ github.event.inputs.next_version }}-SNAPSHOT --stacktrace | |||
| ./gradlew clean release -Dorg.gradle.parallel=false -Prelease.useAutomaticVersion=true -Prelease.pushReleaseVersionBranch=release/${{ github.event.inputs.version_to_release }} -Prelease.releaseVersion=${{ github.event.inputs.version_to_release }} -Prelease.newVersion=${{ github.event.inputs.next_version }}-SNAPSHOT --stacktrace | |||
There was a problem hiding this comment.
This is where I modified the command to create a release branch in Swazzler. I followed the docs for the plugin, but I don't know if it actually works, so we'll have to do by trying it out. This is the part where I'm most unsure about...
| @@ -28,6 +31,7 @@ jobs: | |||
| - name: Checkout Branch | |||
| uses: actions/checkout@v3 | |||
| with: | |||
| ref: release/${{ github.event.inputs.version_to_release }} | |||
There was a problem hiding this comment.
The release is from the release branch, so master is not involved, which is why I could move the version there even before we actually release.
bidetofevil
force-pushed
the
hho/release-actions
branch
from
be47484
to
9dee65e
Compare
Goal
Create a release branch to make any version-specific modifications on and make the release from there. The version number of the SDK will incremented when the release branch is cut, and commits after that will be de facto in the next release. The Swazzler will be updated in the pre-release workflow as it does before.
If there are additional changes that need to go into the release branch, they can be done first in master, then cherrypicked into the release branch.
For hotfixes, the same cherrypicking process will be done, but we will need to add additional GH Actions to ensure to automate the release.