Can you share the download command and URL endpoint? It looks like the command is downloading a text file / website content (Length: text/html) instead of the zip file.
Hi @dnsmichi, thank you for looking into this. As mine was taken directly from the terminal, I was not able to save them. However, this was from my colleague who reported the issue:
Inspected the download button to extract the URL for the CLI: https://gitlab.com/everyonecancontribute/observability/cpp-dns-leaker/-/archive/v0.0.1-kubeconeu2022/cpp-dns-leaker-v0.0.1-kubeconeu2022.zip
I found some discussions which point to longer-term caching refreshments but this feels odd, given that your download commands are fired immediately one after the other.
Git itself only provides git tag and git archive which do not provide a checksum verification functionality nor do tags provide the possibility to upload more assets. This is something GitLab builds on top with Releases linked to Git tags, providing more features and fields. Releases need to be created based on a Git Tag (or in one go from the Git tag creation page), allow you to add a description, upload more assets, and also provide so-called “Release Evidence”.
Release binaries, checksums, etc. can be stored in the generic package repository, and later be linked as release page assets. You can also automate release creation from CI/CD pipelines, which for example generate the release tarball, and checksums and upload them to GitLab using the API. Both files can then be downloaded by clients, and then verified to match.
Hi @dnsmichi, thank you for checking. I am also trying to upgrade the omnibus server that we have but I am met with this error with any version 14.0.X: Failed Upgrade from v13.12.15 to v14
I’ll suggest using tar -tzvf test_release-v0.0.1.tar.gz as the [text/html] suggests some other, changing content is being saved to the tar.gz file. I’ve done this myself so I’m sensitive to the possibility. After 58+ years, I say “assume nothing” more than I would have predicted when much younger.
Hope you can resolve this.
I’m wondering if you’re really downloading the compressed tarball and not some login page.
Another thing to check, if you really get compressed tarballs, are any timestamps embedded. Download two tarballs, compute their checksums, compare the tar tvaf outputs and finally run a diff -rq on the extracted contents to see if there are any differences in content.
Sorry for the delay on this. But going back to @dnsmichi , and I tried his approach and it was already giving out the same checksum. Thank you very much to everyone for your suggestions.
