# Builds are not tagged properly on GitHub releases on Windows **URL:** \ **Category:** Deployment\ **Tags:** build-env, github-integration\ **Created:** [October 26, 2019, 2:42pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682 "2019-10-26T14:42:16Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![phoe](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/phoe/32/3000_2.png) [@phoe](https://travis-ci.community/u/phoe)\ **Post date:** [October 26, 2019, 2:42pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/1 "2019-10-26T14:42:16Z")
Hey hi! I am trying to use GitHub Releases to upload binaries of my compiled code to GitHub. Linux and macOS tag their releases properly, whereas Windows uploads an `untagged-*` release instead. ![Zrzut%20ekranu%20z%202019-10-26%2016-44-02](https://us1.discourse-cdn.com/flex015/uploads/travis_ci/original/2X/b/b68118244bbf38616fb6a1ac6e38b3e68576bbea.png) Build: [https://travis-ci.com/phoe-trash/furcadia-post-splitter/builds/133670864](https://travis-ci.com/phoe-trash/furcadia-post-splitter/builds/133670864) From my own big of debugging, the logs for the `Installing deploy dependencies` step on Linux and macOS say: ```auto Logged in as Michał Herda Deploying to repo: phoe-trash/furcadia-post-splitter Current tag is: latest ``` But the logs on Windows say: ```auto The system cannot find the path specified. The system cannot find the path specified. Logged in as Michał Herda Deploying to repo: phoe-trash/furcadia-post-splitter The system cannot find the path specified. Current tag is: ``` Therefore, to me, it seems that Windows fails to currently recognize that there is a Git tag and therefore uploads an untagged build instead. This would hint that there is a either a bug in my YAML configuration for Travis (which would be weird, because Linux and macOS work properly!), or a bug on how Windows on Travis works (and that is what the lines `The system cannot find the path specified.` seem to hint for). Could you help me diagnose and fix the issue? ---
**Author:** ![phoe](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/phoe/32/3000_2.png) [@phoe](https://travis-ci.community/u/phoe)\ **Post date:** [October 26, 2019, 6:28pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/2 "2019-10-26T18:28:15Z")
Additionally, the tagging behaviour on macOS is different than behaviour on Linux. Tagging the build with `latest` only causes the released files to be uploaded once; if the release is already present on the page, the next release is instead sent to an untagged release instead of overwriting the tagged one. Once again, see [https://github.com/phoe-trash/furcadia-post-splitter/releases](https://github.com/phoe-trash/furcadia-post-splitter/releases) for details. Should I make a separate post for the second issue? ---
**Author:** ![phoe](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/phoe/32/3000_2.png) [@phoe](https://travis-ci.community/u/phoe)\ **Post date:** [November 2, 2019, 10:36pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/3 "2019-11-02T22:36:50Z")
Bump - I have no idea where to start debugging or fixing this issue myself. ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [November 3, 2019, 7:37pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/4 "2019-11-03T19:37:44Z")
> You are building only the `master` branch, so any other build request will be rejected. [https://docs.travis-ci.com/user/deployment/releases#when-tag-is-not-set-at-deployment-time](https://docs.travis-ci.com/user/deployment/releases#when-tag-is-not-set-at-deployment-time) explains what happens if you still try to deploy to GitHub Releases when there is no tag associated with it. ---
**Author:** ![phoe](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/phoe/32/3000_2.png) [@phoe](https://travis-ci.community/u/phoe)\ **Post date:** [November 3, 2019, 8:21pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/5 "2019-11-03T20:21:19Z")
@BanzaiMan Thanks for responding. This is not what my issue is about. The build happens properly when I push to the master branch but the resulting release is not properly tagged. ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [November 3, 2019, 11:24pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/6 "2019-11-03T23:24:42Z")
OK. Then > is not returning anything. ---
**Author:** ![Flamefire](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/flamefire/32/906_2.png) [@Flamefire](https://travis-ci.community/u/Flamefire)\ **Post date:** [November 6, 2019, 9:09am UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/7 "2019-11-06T09:09:34Z")
If you build on commits that are not tagged, set TRAVIS\_TAG to what you would like to use and travis will upload the artifacts to a single release However this only works until you publish a release (aka: draft:false), at this point travis/Github actually tags the commit, permanently adding that tag to the repo. There does not seem to be a way around this and tags cannot/shall not be altered (see `git tag --help` for the -f option) So the idea of a “nightly” release just doesn’t work with github releases unfortunately. Solutions: - Only release on tags - Create tags with e.g. current date - don’t publish until done ---
**Author:** ![phoe](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/phoe/32/3000_2.png) [@phoe](https://travis-ci.community/u/phoe)\ **Post date:** [November 6, 2019, 8:25pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/8 "2019-11-06T20:25:12Z")
I do not really understand the fact that the behaviour is different on all three OSes. - On Linux, the release is uploaded correctly and the old binaries are overwritten. - On macOS, the first release is uploaded correctly and all subsequent ones are untagged. - On Windows, all releases are untagged from the very start. Even if what you described is true, then I see no explanation for this inconsistent behaviour in code that should otherwise be platform-indepdendent (since it’s Ruby on bash, it seems). ---
**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\ **Post date:** [November 6, 2019, 10:13pm UTC](https://travis-ci.community/t/builds-are-not-tagged-properly-on-github-releases-on-windows/5682/9 "2019-11-06T22:13:26Z")
You have 3 jobs defined, one for each of Linux, Windows, and macOS. I’ll use [https://travis-ci.com/phoe-trash/furcadia-post-splitter/builds/133679945](https://travis-ci.com/phoe-trash/furcadia-post-splitter/builds/133679945) as an example of what is happening. Your jobs seem to be _generally_ finishing in this order (Linux, Windows, macOS), but this is _ **not guaranteed** _. 1. The first job to finish is [the linux one](https://travis-ci.com/phoe-trash/furcadia-post-splitter/jobs/249813602). Note that this is _not_ a tagged build, so when we run `git fetch --tags` [https://github.com/travis-ci/dpl/blob/v1.10.13/lib/dpl/provider/releases.rb#L78](https://github.com/travis-ci/dpl/blob/v1.10.13/lib/dpl/provider/releases.rb#L78) There appears to a conflict as to what the `latest` tag should point to. 2. The second job to finish is [the Windows one](https://travis-ci.com/phoe-trash/furcadia-post-splitter/jobs/249813603). This one gets nothing when it runs `git describe --tags --exact-match`. I suspect this is due to the tag conflict I mentioned in the first job, but I am not 100% sure on that. Whatever the reason, you end up with _no_ tag for the release you are uploading file(s), so GitHub creates one, as described in 3. Finally, [the macOS job](https://travis-ci.com/phoe-trash/furcadia-post-splitter/jobs/249813604) finishes. You will notice that when tags are fetched during the deployment stage, the `latest` tag is _updated_ (line 842) and the new tag `untagged-*` created by the Windows job is fetched (line 843). Because there are multiple tags associated with this current commit now, but it was not a tagged build in the first place, we run `git describe --tags --exact-match`, which now returns `untagged-*`. So the assets for this job will be uploaded to this release. In general, it is not a good idea to not use tags for GitHub Releases. There are certain workflows in which not using tags is beneficial. But your setup doesn’t seem to be one.