Fix tag format of container when building tag #84
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.
Another PR that addresses #63.
Doing a
captain build
when on a tagged commit currently causes aerroneous tag name. For example, if on a tag v1.0 of a repository, when
the captain build occurs, this this the output:
Notice the
tags.v1.0^0
. That is wrong on two fronts. 1.) the tag shouldbe
v1.0
and 2.) the carrot symbol^
makes it an invalid format for adocker tag.
The problem occurs when obtaining the branch names. The code uses the
command
git name-rev --name-only HEAD
to determine the branch name.This used to work. However, git must have changed over the years because
if you are on a tag, this now returns
tags.v1.0^0
.Fortunately, the same command has an
--exclude
parameter that willallow us to indicate to filter out tags (which is what we wanted anyway
for that particular call). The tags are determined later via the git
command
git tag --points-at HEAD
. (all of these references occur ingit.go
)When running tests, as they currently are, they failed for this very
reason. After excluding tags with the
--exclude
parameter to the gitcommand, all the tests pass. (I am running git version 2.17.1 on Ubuntu
18.04)
Please accept this PR and create a new distributable so I and others do
not run into this again.