(maint) Properly install pe-client-tools when using a tag version #69
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, installing pe-client-tools with a tag version would fail on Windows/OS X and install the wrong package on Linux. When installing pe-client-tools, we provide two options: - pe_client_tools_sha: the commit SHA of the version to install - pe_client_tools_version: the `git describe` of the version to install pe_client_tools_version is always the name of the package to install. But the *location* of the package differs based on whether the package version corresponds to a tag or not. When the package isn't a tag version, it's located in a directory named based on the SHA. But when it is a tag version, it's located in a directory named after the tag. When pe_client_tools_version was specified as a tag, we would look in the directory named after the SHA (which was actually from a *previous* build of the package, from before it was tagged) for a file named after the tag. That file would never be there, since we had a mismatch of directory and filename. For Windows and OS X, this caused a failure to install, because they need to know the exact filename. This case incidentally *worked* (or appeared to work) on Linux platforms, because they never actually refer to the package by filename. Instead, they install the package by setting up a repo config, which *is* always named after pe_client_tools_sha, and never pe_client_tools_version. In that case, the Linux platforms would actually install the previous version of the package by SHA, from before it had been tagged. We now properly handle the case where pe_client_tools_version is a tag, by using that version as the location of the file in addition to the filename.
|
Can one of the admins verify this patch? |
MikaelSmith
approved these changes
May 4, 2017
|
Refer to this link for build results (access rights to CI server needed): |
|
@puppetlabs/beaker If anyone has a moment, this issue is breaking orchestrator-client tests, so I'd love a review. |
kevpl
approved these changes
May 5, 2017
|
@kevpl This looks fine to merge and release. I don't believe we install the client tools separately in any of the integration pipeline tests (pe_acceptance_tests). |
|
Seems like this is ready to go. Does it need any additional input from me? |
|
Can one of the admins verify this patch? |
|
ping |
|
Since pe_acceptance_tests is pinned to 1.11.0 on all branches, I'm going to go ahead and merge and release this change. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.
When installing pe-client-tools, we provide two options:
git describeof the version to installpe_client_tools_version is always the name of the package to install.
But the location of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.
When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a previous
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.
This case incidentally worked (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which is always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.
We now properly handle the case where pe_client_tools_version is a tag,
by using that version as the location of the file in addition to the
filename.