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

feat: set a better version for dev builds #1415

Merged
merged 6 commits into from
Nov 12, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 16 additions & 5 deletions build-docker.sh
Original file line number Diff line number Diff line change
Expand Up @@ -15,12 +15,23 @@ if [[ "${CIRCLE_BRANCH}" == "main" ]]; then
TAGS+=",latest"
fi

# Local builds just get "dev" for version
VERSION="dev"
# Determine a version number based on most recent version tag in git.
# git describe - Return the most recent annotated tag that is reachable from a commit.
# --tags - OK, any tag, not just the annotated ones. We don't always remember to annotate a version tag.
# --match='v[0-9]*' - But of all those tags, only the version ones (starts with a v and a digit).
# --always - … and if a tag can't be found, fallback to the commit ID.
# Ex: v2.1.1-45-ga1b2c3d
# - The build was on git commit ID a1b2c3d.
# - 2.1.1 is the most recent version tag in the history behind that commit
robbkidd marked this conversation as resolved.
Show resolved Hide resolved
# - That commit is 45 commits ahead of that version tag.
VERSION=$(git describe --tags --match='v[0-9]*' --always)

# If we are doing a dev build on circle, we will version it as the circleci buildnumber
if [[ -n "${CIRCLE_BUILD_NUM}" ]]; then
VERSION="${CIRCLE_BUILD_NUM}"
# If we are doing a dev build on circle, append the build number (job id) to the version
# Ex: v2.1.1-45-ga1b2c3d-ci8675309
# - The git information gleaned above plus ...
# - The build happened within CircleCI job 8675309.
if [[ -n "${CIRCLE_BUILD_NUM:-}" ]]; then
VERSION="${VERSION}-ci${CIRCLE_BUILD_NUM}"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
VERSION="${VERSION}-ci${CIRCLE_BUILD_NUM}"
VERSION="${VERSION}-${CIRCLE_BUILD_NUM}"

So I love the general idea of this. However, I find the full version a bit distracting with the extra descriptors. I also wonder if the 45 commits is necessary. I don't know if it's possible to drop the g, but I feel like it would be clearer if we dropped the g and the ci.

A radical idea could be something like...

v2.8.2-45-ge527ea1-ci8675309 becomes v2.8.2+e527ea1_8675309

Copy link
Contributor

Choose a reason for hiding this comment

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

Personally, I don't see the value in the 45. I also like dropping g and ci, but I don't think we win much with the + and _ -- I'd rather see dashes or underscores everywhere.

Copy link
Contributor

Choose a reason for hiding this comment

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

I like the idea to quickly know how much deviation between a dev build and the last stable release. Since the CI build ID is always a number, I find it helpful to have the ci prefix to remind me what the number is. However, I agree that the g for git is not as helpful since commit hash also contains letters.

Copy link
Member Author

Choose a reason for hiding this comment

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

Starting with defaults, the 45 and the g is what comes out of the git describe command:

❯ git describe --tags --match='v[0-9]*' --always
v2.8.2-45-ge527ea1

g for git is not as helpful since commit hash also contains letters

I agree that's annoying. I happen to know that commit IDs are SHA1 hashes and SHA1 hashes are hexadecimal and g is not a hex digit, so my brain parses that fine and it doesn't bother me that much. … But as I list all that out, I see that it takes me knowing a lot of things to get to the point of it not bothering me much.

So my current tolerance for this format is such that I am currently not convinced that the added complexity to shape this dev version differently will be worth writing and maintaining. I am open to being convinced, though.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's not worth fixing that for a minor annoyance. I'm going to approve this, but it might be useful to also hear from others before merging.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, that's makes much more sense. Thank you for the explanation. My brain can now process it better. Always learning something new from Robb.

I agree with you that this is not something that worth adding more complexity for

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, not worth the added effort. This gives me so much information so I'm plenty pleased 😃

Copy link
Contributor

Choose a reason for hiding this comment

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

I also don't find much value in the ci prefix for circle build IDs. I'm don't mind the hyphen's or the number of commits as they match the default git format.

Also agree there's we've been blocked on this for awhile, we can always come back and change it if needed but this better than what we have now.

fi

# if we're running off a git tag, it is a release which we tag with the versions as well as latest
Expand Down