Invalid tag format? #63
Comments
|
I was able to reproduce this by creating a new repo $ git init
$ touch README.md
$ git add README.md
$ git commit -am 'Testing'
$ git tag -a 1.0.0
$ captain build
When you issue the command that captain is looking at for branches
```bash
$git name-rev --name-only HEADYou get tags/1.0.0^0Seems unusual, but I added a small fix to get rid of this. Seems to work fine. |
|
I just encountered the same error. Is that already fixed? The issue also happens when using captain 1.1.2 - I'm running the build on debian stretch. |
|
Same error here. |
jwliechty
added a commit
to jwliechty/captain
that referenced
this issue
Apr 22, 2019
Another PR that addresses harbur#63. Doing a `captain build` when on a tagged commit currently causes a erroneous tag name. For example, if on a tag v1.0.0 of a repository, when the captain build occurs, this this the output: ``` [CAPTAIN] Skipping build of image my_organization/my_image_name:da5ewb3 - image is already built [CAPTAIN] Tagging image my_organization/my_image_name:da5ewb3 as my_organization/my_image_name:latest [CAPTAIN] Tagging image my_organization/my_image_name:da5ewb3 as my_organization/my_image_name:tags.v1.0^0 API error (500): {"message":"invalid tag format"} ``` Notice the `tags.v1.0^0`. That is wrong on two fronts. 1.) the tag should be `v1.0` and 2.) the carrot symbol `^` makes it an invalid format for a docker 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`. Forturnately, the same command has an `--exclude` parameter that will allow us to indicate to filter out tags (which is what we wanted anyway for that particalar call). The tags are determined later via the git command `git tag --points-at HEAD`. (all of these refererences occur in `git.go`. When running tests, as they currently are, they failed for this very reason. After excluding tags with the `--exclude` parameter to the git command, 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 other do not run into this again.
jwliechty
added a commit
to jwliechty/captain
that referenced
this issue
Apr 22, 2019
Another PR that addresses harbur#63. Doing a `captain build` when on a tagged commit currently causes a erroneous tag name. For example, if on a tag v1.0 of a repository, when the captain build occurs, this this the output: ``` [CAPTAIN] Skipping build of image my_organization/my_image_name:da5ewb3 - image is already built [CAPTAIN] Tagging image my_organization/my_image_name:da5ewb3 as my_organization/my_image_name:latest [CAPTAIN] Tagging image my_organization/my_image_name:da5ewb3 as my_organization/my_image_name:tags.v1.0^0 API error (500): {"message":"invalid tag format"} ``` Notice the `tags.v1.0^0`. That is wrong on two fronts. 1.) the tag should be `v1.0` and 2.) the carrot symbol `^` makes it an invalid format for a docker 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 will allow 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 in `git.go`) When running tests, as they currently are, they failed for this very reason. After excluding tags with the `--exclude` parameter to the git command, 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.
|
fixed by #84 and released on v1.1.3 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
During tagging after a build
xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/ss:tags.1.0.1^0 <- no idea how this got there
API error (500): {"message":"invalid tag format"}
The text was updated successfully, but these errors were encountered: