ci(snapshot): skip deploy if no snapshot version or release version #238
Conversation
v1v
changed the title
.github/workflows/release.yml
Outdated
| @@ -51,6 +51,15 @@ jobs: | |||
| echo "Tag should match pom.xml project.version" | |||
| exit 1 | |||
| fi | |||
| - uses: ./.github/workflows/maven-goal | |||
There was a problem hiding this comment.
Do we even need this here? Don't we check for exact equality with the provided end.RELEASE_VERSION above?
Someone would need to actually provide 1.6.0-SNAPSHOT here to accidentally release a snapshot?
Disclaimer: I'm a shell scripting noob
There was a problem hiding this comment.
Do we even need this here? Don't we check for exact equality with the provided
end.RELEASE_VERSIONabove?
You are right!
Although I'm a bit confused about the reason for using the inputs.version, IIUC, it should be the pre-release workflow, the one bumping the version and the release workflow, the one using the pom.xml file, to do the release. Hence inputs.version is not something we need at all, the buildkite pipeline is not using it.
There was a problem hiding this comment.
Someone would need to actually provide 1.6.0-SNAPSHOT here to accidentally release a snapshot?
Or change the pom.xml version in a different and use a different inputs.ref.
I think the validation is still valid and in fact, the checkout for the given ref is needed, I'll do the change now
| @@ -40,6 +40,7 @@ jobs: | |||
| - name: Checkout | |||
| uses: actions/checkout@v4 | |||
| with: | |||
| ref: ${{ inputs.ref }} | |||
There was a problem hiding this comment.
Fail fast if the ref is not correct. Otherwise, it's required to wait for the Buildkite pipeline to run
| @@ -51,6 +52,12 @@ jobs: | |||
| echo "Tag should match pom.xml project.version" | |||
| exit 1 | |||
| fi | |||
| - name: Validate version is a release version | |||
There was a problem hiding this comment.
Otherwise, the pom.xml version is a snapshot.
What
Why
The release process has been changed to accommodate the branch protection, and hence, the main will contain a release version until the PR with the snapshot version is merged.
Therefore, the snapshot GitHub action will run when it should not!
In addition, let's avoid the corner case where the
pom.xmlfile contains a SNAPSHOT version and theinputs.refpoints to that particular git reference.Test
### Issues
Caused by #226