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

rename Dockerfile build-arg VERSION to PRODUCT_VERSION #14369

Merged
merged 2 commits into from
Mar 10, 2022

Conversation

alvin-huang
Copy link
Collaborator

We pass in PRODUCT_VERSION in our docker build action so we need to reference it in our Dockerfile here to set the right version label.

The concern is there may be folks using the current Dockerfile with tooling that sets --build-arg VERSION=x.y.z and this will break them especially if they check the label for the current version like we do in the action. What do you think @samsalisbury ?

Makefile Outdated

docker-dev-ui: prep
docker build --build-arg VERSION=$(GO_VERSION_MIN) --build-arg BUILD_TAGS="$(BUILD_TAGS)" -f scripts/docker/Dockerfile.ui -t vault:dev-ui .
docker build --build-arg PRODUCT_VERSION=$(GO_VERSION_MIN) --build-arg BUILD_TAGS="$(BUILD_TAGS)" -f scripts/docker/Dockerfile.ui -t vault:dev-ui .
Copy link
Contributor

Choose a reason for hiding this comment

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

This and the target above seem to be referencing ./scripts/docker/Dockerfile[.ui] so they shouldn't need updating based on the change to the ./Dockerfile as far as I can see. The VERSION in these Dockerfiles is the Go version, as opposed to the product version. (This is why I always use PRODUCT_VERSION for the product version, not just VERSION as it helps to disambiguate all the different things with versions we're dealing with :) )

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good catch! Just changed it back!

@vercel vercel bot temporarily deployed to Preview – vault March 4, 2022 15:18 Inactive
@vercel vercel bot temporarily deployed to Preview – vault-storybook March 4, 2022 15:18 Inactive
@alvin-huang
Copy link
Collaborator Author

@samsalisbury do you think renaming VERSION will be an issue for anyone that might happen to be building the Dockerfile themselves (externally)?

@samsalisbury
Copy link
Contributor

@samsalisbury do you think renaming VERSION will be an issue for anyone that might happen to be building the Dockerfile themselves (externally)?

Hi @alvin-huang, if other people are using this particular Dockerfile it would break their build, but I wouldn't be too concerned about it because this is a new(ish) file, and is geared really specifically towards producing release builds using CRT. See especially the COPY on line 23.

@alvin-huang alvin-huang requested a review from mladlow March 7, 2022 15:56
@alvin-huang
Copy link
Collaborator Author

Sounds good to me, thanks! @mladlow, tagged you as more of an FYI

@samsalisbury samsalisbury merged commit 0ee2ac3 into main Mar 10, 2022
@samsalisbury samsalisbury deleted the ci/rename-docker-variables branch March 10, 2022 12:59
@alvin-huang
Copy link
Collaborator Author

@mladlow this should be backported to any release lines you will be releasing with CRT

@mladlow
Copy link
Collaborator

mladlow commented Mar 16, 2022

@alvin-huang typically we'd ask the PR author to handle the backports. In the event of conflicts, they're the most familiar with how to resolve them. We shouldn't need any additional 1.7 releases, but would need backports to release/1.10.x, release/1.9.x, and release/1.8.x. Can you all take this on? If that's not possible, I can find someone else to do it.

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.

3 participants