Adds workflows to create ion-java prerelease on GitHub.#452
Conversation
Codecov Report
@@ Coverage Diff @@
## master #452 +/- ##
=========================================
Coverage 66.54% 66.55%
- Complexity 5410 5411 +1
=========================================
Files 156 156
Lines 22761 22761
Branches 4105 4105
=========================================
+ Hits 15147 15149 +2
+ Misses 6249 6247 -2
Partials 1365 1365
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
This PR doesn't contain version number bump and will not trigger the ion-java GitHub prerelease process. |
| cd current_release | ||
| git submodule init | ||
| git submodule update | ||
| mvn clean install |
There was a problem hiding this comment.
This causes the tests to be run. I'd be okay skipping that, since this workflow will only be run when previous workflows have confirmed the tests pass. Let's use mvn clean install -DskipTests.
There was a problem hiding this comment.
This causes the tests to be run. I'd be okay skipping that, since this workflow will only be run when previous workflows have confirmed the tests pass. Let's use
mvn clean install -DskipTests.
Thanks for the suggestion, I'll update this.
| comment-when-version-number-check-failed: | ||
| needs: check-version-bump | ||
| if: ${{ failure() }} | ||
| runs-on: ubuntu-latest | ||
| name: comment-when-version-number-check-failed | ||
| steps: | ||
| - name: Create comment | ||
| uses: peter-evans/create-or-update-comment@v2 | ||
| with: | ||
| issue-number: ${{ github.event.pull_request.number }} | ||
| body: | | ||
| This PR doesn't contain version number bump and will not trigger the ion-java GitHub prerelease process. |
There was a problem hiding this comment.
This is the normal case, correct? For example, this will happen when someone creates a PR for a bug fix. In this case, I'd expect that no comment would be posted and the workflow would succeed immediately without running the fast-forward check.
There was a problem hiding this comment.
This is the normal case, correct? For example, this will happen when someone creates a PR for a bug fix. In this case, I'd expect that no comment would be posted and the workflow would succeed immediately without running the fast-forward check.
Yes. That sounds more reasonable to me, I'll update this in the following commit.
| with: | ||
| issue-number: ${{ github.event.pull_request.number }} | ||
| body: | | ||
| This PR passes version bump check and fast-forward check, please double check the version number and merge this PR. After merging this PR, please trigger "Create gitHub prerelease after fast-forward check" workflow manually to create prerelease. |
There was a problem hiding this comment.
Consider adding instructions for how to manually trigger the workflow. Is there any way to trigger it automatically upon merge of the PR?
There was a problem hiding this comment.
Consider adding instructions for how to manually trigger the workflow. Is there any way to trigger it automatically upon merge of the PR?
Good catch. Ideally, this PR should be triggered when version-bump-and-fast-forward-check finished and the version bump PR got merged. We can make both of them as trigger events of the create prerelease workflow. However, I'm thinking about it would be more practical if we can make the version number check as a separate workflow and reuse it in both fast-forward check and create release workflow. And update the trigger event of create release as PR merged. That way, we can also avoid creating a prerelease without updating the version number cause before creating release we will check the version number change.
| - name: Create new release | ||
| id: create_new_release | ||
| uses: actions/create-release@v1 | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| with: | ||
| tag_name: v${{ env.version_number }} | ||
| release_name: v${{ env.version_number }} | ||
| prerelease: true |
There was a problem hiding this comment.
Can we verify in this workflow that no release for this version already exists? That would ensure that we don't accidentally create a new release without updating the version.
There was a problem hiding this comment.
Can we verify in this workflow that no release for this version already exists? That would ensure that we don't accidentally create a new release without updating the version.
This workflow will be triggered manually after the version bump PR merged, but I agree. It would be a good idea to add one step to check the version number change in case this workflow is triggered accidentally.
Using 'mvn clean install -DskipTests' to skip the tests when building ion-java. Update the output of version-number-check. Update the trigger event of prerelease creating workflow and add one step to check the version number.
Yes, sure. Thanks for catching this. |
Updates the method of getting ion-java version number. Updates the condition expression when creating comment after fast-forward check.
Issue #, if available:
N/A
Description of changes:
This PR adds two workflows to create ion-java GitHub pre-release. In the workflow, there are some steps to help check version number bump and also check whether the new release is fast-forward compared to the last release. Here are some explanation and examples about how these workflows work.
This workflow will be triggered when there is a PR created. The first part of this workflow is to check whether this new PR contains version number change. If there is no version number bump included in this PR, the workflow will be executed successfully without executing the steps of checking fast-forward. Here is the example: No version bump linlin-s/ion-java#23
Version bump linlin-s/ion-java#24
Here is an example of when version bump check passes but the fast-forward check doesn't:
linlin-s#24
This workflow contains two jobs, and it will be triggered whenever there is a PR get merged. The first job is to check the version number bump. If there is no version number change, the next job -- create prerelease will be skipped and the workflow will be executed successfully. Here is an example:

If the version bump check passed, the prerelease of the new version of ion-java will be created. It will build the new version of ion-java then upload the executable jar file to the prerelease assets. Then developers can keep editing the release note and publish the release, Here is an example of prerelease generated by triggering this workflow.https://github.com/linlin-s/ion-java/actions/runs/3271080245


https://github.com/linlin-s/ion-java/releases/tag/v1.9.8
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.