Skip to content

Adds workflows to create ion-java prerelease on GitHub.#452

Merged
linlin-s merged 3 commits intomasterfrom
autoRelease
Oct 19, 2022
Merged

Adds workflows to create ion-java prerelease on GitHub.#452
linlin-s merged 3 commits intomasterfrom
autoRelease

Conversation

@linlin-s
Copy link
Copy Markdown
Contributor

@linlin-s linlin-s commented Oct 3, 2022

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.

  • Version-bump-and-fast-forward-check:
    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

image

  • If there is version number bump in this PR, the workflow will trigger the job of fast-forward check. If the commit id of the last release is ancestor of the incoming PR commit id, the fast-forward check will be passed. When both version number bump check and fast-forward check pass, the workflow will throw a comment on this PR:
    Version bump linlin-s/ion-java#24

image

Here is an example of when version bump check passes but the fast-forward check doesn't:
linlin-s#24

image

  • Create GitHub prerelease after fast-forward check:
    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:

image

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
image
https://github.com/linlin-s/ion-java/releases/tag/v1.9.8
image

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@codecov
Copy link
Copy Markdown

codecov Bot commented Oct 3, 2022

Codecov Report

Merging #452 (09a5df8) into master (3fa4980) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            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           
Impacted Files Coverage Δ
src/com/amazon/ion/impl/BlockedBuffer.java 51.21% <0.00%> (+0.24%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Oct 3, 2022

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 on lines +31 to +42
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding instructions for how to manually trigger the workflow. Is there any way to trigger it automatically upon merge of the PR?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +30 to +38
- 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@linlin-s linlin-s requested a review from tgregg October 13, 2022 22:52
Copy link
Copy Markdown
Contributor

@tgregg tgregg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, but could you please update the description so that it describes the current state of the workflows? I have a feeling this description will be used as documentation for how the workflows work, so we want the info to be accurate.

@linlin-s
Copy link
Copy Markdown
Contributor Author

This looks could, but could you please update the description so that it describes the current state of the workflows? I have a feeling this description will be used as documentation for how the workflows work, so we want the info to be accurate.

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.
@linlin-s linlin-s merged commit 57bd49b into master Oct 19, 2022
@linlin-s linlin-s deleted the autoRelease branch January 16, 2024 19:25
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.

2 participants