Skip to content

Update nightly builds to use Golang pseudo-version#125

Merged
docker-unir[bot] merged 1 commit intodocker:masterfrom
thaJeztah:a_nightly_to_remember
Jul 20, 2018
Merged

Update nightly builds to use Golang pseudo-version#125
docker-unir[bot] merged 1 commit intodocker:masterfrom
thaJeztah:a_nightly_to_remember

Conversation

@thaJeztah
Copy link
Copy Markdown
Member

based on golang's pseudo-version: https://groups.google.com/forum/#!topic/golang-dev/a5PqQuBljF4

using a "pseudo-version" of the form v0.0.0-yyyymmddhhmmss-abcdefabcdef,
where the time is the commit time in UTC and the final suffix is the prefix
of the commit hash. The time portion ensures that two pseudo-versions can
be compared to determine which happened later, the commit hash identifes
the underlying commit, and the v0.0.0- prefix identifies the pseudo-version
as a pre-release before version v0.0.0, so that the go command prefers any
tagged release over any pseudo-version.


DATE_COMMAND="date"
if [[ $(uname) -eq "Darwin" ]]; then
DATE_COMMAND="docker run --rm alpine date"
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Looks like this was because macOS date doesn't have --date="string"?

I replaced this for echo "datestring" | xargs date -d ....

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Argh; looks like that doesn't work on macOS after all 😕

# the underlying commit, and the v0.0.0- prefix identifies the pseudo-version
# as a pre-release before version v0.0.0, so that the go command prefers any
# tagged release over any pseudo-version.
gitUnix="$($GIT_COMMAND log -1 --pretty='%ct')"
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

note: changed %at (author date) to %ct (committer date) - author date can be days in the past, i.e., not matching the date that the commit was merged

gitDate="$(echo @${gitUnix} | xargs date +'%Y%m%d%H%M%S' -u -d)"
gitCommit="$($GIT_COMMAND log -1 --pretty='%h')"
debVersion="0.${gitDate}-${gitCommit}"
debVersion="0.0.0-${gitDate}-${gitCommit}"
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

IIUC; both deb and rpm don't expect the v prefix

# $ dpkg --compare-versions 18.06.0-ce-rc3 gt 18.06.0-ce-rc2 && echo true || echo false
# true
# $ dpkg --compare-versions 18.06.0-ce gt 18.06.0-ce-rc2 && echo true || echo false
# false
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Noticed this one; curious how we resolved that

Copy link
Copy Markdown
Contributor

@seemethere seemethere Jul 19, 2018

Choose a reason for hiding this comment

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

We add some magic sorting numbers at around line 30

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I honestly think we should just remove these comments in general, they haven't really been relevant for a while.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, I ran them to verify the new version did what we expected

We should put this all in a function (looks like it's basically the same in deb, rpm and static) .. but that's for a follow-up

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I guess the comments are misleading since they don't accurately reflect the final outcome, but I like the idea of being able to see the functionality.

@thaJeztah
Copy link
Copy Markdown
Member Author

ping @seemethere @andrewhsu PTAL (please double-check; I tested it out-of-band in a shell)

based on golang's pseudo-version: https://groups.google.com/forum/#!topic/golang-dev/a5PqQuBljF4

> using a "pseudo-version" of the form v0.0.0-yyyymmddhhmmss-abcdefabcdef,
> where the time is the commit time in UTC and the final suffix is the prefix
> of the commit hash. The time portion ensures that two pseudo-versions can
> be compared to determine which happened later, the commit hash identifes
> the underlying commit, and the v0.0.0- prefix identifies the pseudo-version
> as a pre-release before version v0.0.0, so that the go command prefers any
> tagged release over any pseudo-version.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah force-pushed the a_nightly_to_remember branch from ee54823 to d2baf8f Compare July 19, 2018 22:28
Copy link
Copy Markdown
Contributor

@seemethere seemethere left a comment

Choose a reason for hiding this comment

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

LGTM, I'll need to check with our nightly build reaper to see if it works correctly with that but as far as this PR goes I think it should work.

@seemethere
Copy link
Copy Markdown
Contributor

P.S. I love your feature branch name @thaJeztah ❤️

@thaJeztah
Copy link
Copy Markdown
Member Author

P.S. I love your feature branch name @thaJeztah ❤️

LOL, should see some of my other ones 😂

@seemethere seemethere requested a review from a team July 20, 2018 16:09
Copy link
Copy Markdown

@jose-bigio jose-bigio left a comment

Choose a reason for hiding this comment

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

I am wondering what benefit we will have from using a pseudo-version?

From my understanding the benefit of a pseudo-version is that it would allow people to go get modules in a better fashion. However, this is changing deb and rpm packages to use pseudo-version.

Does this somehow make it easier for people to consume the nightly packages?

@jose-bigio
Copy link
Copy Markdown

jose-bigio commented Jul 20, 2018

In response to my own comment catching up on:
https://github.com/docker/release-packaging/issues/181#issuecomment-406405743

to better understand the need for this change.

I was even cced on the discussion 🤦‍♂️

@jose-bigio
Copy link
Copy Markdown

After reading the discussion my understanding is that we want to make this change because it could become a standard.

I haven't really given much thought to whether one versioning scheme (the original) is better than the other, but am fine either way.
I understand the timeliness of this change, but want to point out that it seems one of the motivations for the change seems to be based on the assumption that this could become the standard.

My apologies for discussing this a little late, but wanted to talk about it before we brought it in.

@thaJeztah
Copy link
Copy Markdown
Member Author

I think the big advantage is that it's valid semver and provides all the information that's needed (time committed, git sha); in addition to something becoming more of a standard (instead of a self-defined format)

@thaJeztah
Copy link
Copy Markdown
Member Author

If we would not take this change; we should still merge the fix for the right commit date; currently I think it's possible we go back in time (ie a PR merged that was rebased, but authored a long time ago)

Copy link
Copy Markdown

@jose-bigio jose-bigio left a comment

Choose a reason for hiding this comment

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

LGTM

@docker-unir docker-unir bot merged commit a5aa7e5 into docker:master Jul 20, 2018
@thaJeztah thaJeztah deleted the a_nightly_to_remember branch July 20, 2018 18:12
@thaJeztah
Copy link
Copy Markdown
Member Author

documentation updates in docker/docs#7090

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants