Skip to content
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

Merged
merged 4 commits into from
Jun 15, 2021

Conversation

devinrsmith
Copy link
Member

@devinrsmith devinrsmith commented Jun 1, 2021

… release branches.

These changes are part of the history leading up to tag v0.1.0.

@devinrsmith devinrsmith added the ci label Jun 1, 2021
@devinrsmith devinrsmith added this to the June 2021 milestone Jun 1, 2021
@devinrsmith devinrsmith requested a review from mofojed June 1, 2021 19:15
@devinrsmith devinrsmith self-assigned this Jun 1, 2021
.github/workflows/check-ci.yml Show resolved Hide resolved
@@ -19,15 +19,24 @@ jobs:
with:
java-version: '8.0.292'

- name: Get Semver
id: semver
if: ${{ startsWith(github.ref, 'refs/heads/release/v') }}
Copy link
Member

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?

Copy link
Member Author

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 Show resolved Hide resolved
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
Copy link
Member

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?

Copy link
Member Author

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.

docker/metadata-action#80

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)
@devinrsmith devinrsmith merged commit f462256 into deephaven:main Jun 15, 2021
@devinrsmith devinrsmith deleted the release-process-improvements branch June 15, 2021 15:09
jmao-denver pushed a commit to jmao-denver/deephaven-core that referenced this pull request Apr 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants