tarball downloads for tags can contain commit hash in root folder name

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Depending on the exact URL that's used for downloading the tarball for a git tag / release, the root folder in the downloaded tarball has a different name. This is especially annoying because when you download a project's release tarball, you don't know the exact commit that corresponds to the git tag. For example, for RPM packaging, the root directory name of the source tarball needs to be known and predictable (e.g. contain only $PROJECT and $VERSION). Hard-coding a commit hash there defeats that purpose ...

Steps to reproduce

Downloading the tarball for the 1.25 release (unhelpfully tagged VERSION_1.25) of accounts-sso/libaccounts-glib, there are two different outcomes depending on the "filename" portion of the download URL.

  1. use expected tarball name: root directory contains the tag name AND the commit hash

URL: https://gitlab.com/accounts-sso/libaccounts-glib/-/archive/VERSION_1.25/libaccounts-glib-1.25.tar.gz

Tarball root directory: libaccounts-glib-VERSION_1.25-886a80b3ba975d8a59a6500ade2b1debb552660c

  1. use weird tarball name: root directory contains tag name

URL: https://gitlab.com/accounts-sso/libaccounts-glib/-/archive/VERSION_1.25/libaccounts-glib-VERSION_1.25.tar.gz

Tarball root directory: libaccounts-glib-VERSION_1.25

Example Project

https://gitlab.com/accounts-sso/libaccounts-glib/-/tags/VERSION_1.25

What is the current bug behavior?

Name of the root directory of the downloaded tag tarball is dependent on the filename of the download.

What is the expected correct behavior?

Name of the root directory of the downloaded tarball has the format $PROJECT-$TAG, regardless of the specified filename. This is also the behaviour of tarball downloads for tags / releases on GitHub.

Relevant logs and/or screenshots

None

Output of checks

This bug happens on GitLab.com.

Possible fixes

Since this is probably caused by checking too much (in this case, the exact download URL), where the specified filename should actually not influence the produced tarball, this should only be a matter of removing the condition that triggers the unexpected behaviour.

Edited by 🤖 GitLab Bot 🤖