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.
From my own big of debugging, the logs for the Installing deploy dependencies step on Linux and macOS say:
Logged in as Michał Herda
Deploying to repo: phoe-trash/furcadia-post-splitter
Current tag is: latest
But the logs on Windows say:
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).
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 for details.
Should I make a separate post for the second issue?
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.
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).
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 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.
I believe this happens because you are force-pushing the tag latest over and over.
This job proceeds to upload the file, clobbering the existing asset, since it is pointing to the same release.
The second job to finish is the Windows one. 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
Finally, the macOS job 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.
