-
Notifications
You must be signed in to change notification settings - Fork 78
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
Improve release process, ensure proper docker tags, ensure CI jobs on… #686
Improve release process, ensure proper docker tags, ensure CI jobs on… #686
Conversation
… release branches
@@ -19,15 +19,24 @@ jobs: | |||
with: | |||
java-version: '8.0.292' | |||
|
|||
- name: Get Semver | |||
id: semver | |||
if: ${{ startsWith(github.ref, 'refs/heads/release/v') }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this is possible, but startsWith(github.ref, 'refs/heads/release/v')
is used in a bunch of places, can that be initialized at the start and re-used? Maybe as an env variable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of workflow yml duplication (ie, the java version too) - I don't think there's a "proper" way to do de-duplication at the configuration level (GH yaml doesn't support yaml anchors :/). Changing the environment may work, but is technically fragile since the values can change at runtime. Will investigate.
.github/workflows/build-ci.yml
Outdated
type=semver,pattern={{version}} | ||
type=semver,pattern={{major}}.{{minor}} | ||
type=raw,priority=950,priority=950,enable=${{ startsWith(github.ref, 'refs/heads/release/v') }},value=${{ steps.semver.outputs.semver }} | ||
type=raw,enable=${{ startsWith(github.ref, 'refs/heads/release/v') }},value=latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading this right, won't this add the tag latest
when doing a push back to any release branch? If we have v2.0.0
, and v1.5.0
, and then we patch 1.5 to make v1.5.1
, won't that get tagged latest
when v2.0.0
should still be latest
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - that's the problem w/ the latest
tag in general - I've noticed a lot of projects fall into this trap.
It can be solved by guarding the latest tag against a specific ref - I could update this to
type=raw,enable=${{ startsWith(github.ref, 'refs/heads/release/v0.2') }},value=latest
, and we just need to make sure when we do version bump, we also update this.
…rovements * upstream/main: Update badges (deephaven#676) removed the use of DH's own numba annotations, fixes deephaven#630 (deephaven#681) Bring missed RspArray packing from DHE, including latest bugfix for AIOOBE. Fixes deephaven#687. (deephaven#688)
… release branches.
These changes are part of the history leading up to tag v0.1.0.