my company hosts a private GitLab instance where I don’t have any administrative control over, am just allowed to do whatever (most?) users are allowed to do. While I can create groups and repos, I’m e.g. not able to customize system wide defaults according to my tests.
We maintain software which doesn’t need to be installed, it’s simply about downloading e.g. a ZIP archive with lots of files and directories, placing those somewhere and use the software. That software consists of a source and binary part, the former necessary to build the latter of course. Both parts are maintained in GitLab using individual repos, so that all binary versions provided to customers can be properly tracked as well. Additionally, lots of the deployment consists of textual, source like files again, so having DIFFs on those in case of necessary debugging makes sense as well. Some customers really clone/fork their binary repo and maintain their own configs and customizations of the software this way.
Though, not all customers are willing or able to deal with GIT that way and simply want a ZIP download. That is currently created using the web API to create file archives and a web access token for the customers repo. The following is an example:
This results in an archive with the following name, containing a directory with the same name as well:
bkkd is the name of the repo,
v2-v2.11.1 is the tag I was interested in and everything else the commit hash the tag points to currently. While all of that makes sense, it looks pretty verbose to some customers and concepts like a commit hash aren’t of too much interest to them. Instead, sometimes tags are even forcefully updated to point to new commits and newly downloaded ZIPs with the same tag should really overwrite formerly downloaded ZIPs. Additionally, some more descriptive prefix instead of only the repo name might make sense as well. That short name is only to keep URLs short, while those create a pretty complex hierarchy of repos for different customers with meaningful names being shown in the web-UI.
What I would like to have as ZIP and contained root directory is something like the following instead:
This means some static prefix, no commit hash and leaving the tag name. Of course it would be best to even reduce that to
v2.11.1 as well, but those things are not too important.
Looking at the docs of the API, it doesn’t seem like this level of influence is possible currently?
The only influence on the name I can see is choosing the
Is there some way to make use of
It would be great to have those kinds of things per repo and tracked at the same time, without the need to configure something in the web-UI. Though, the only keywords
export-subst don’t seem to help me.
Or is the only chance to setup a build pipeline creating the archive on its own?
I hoped to avoid that, because creating the archive on the fly is fast enough for me and I would like to not need to deal with cleanup of build artifacts and stuff.
Thanks for your hints!