No way to disable auto-generated source code zip links

[kornelski]

GitHub automatically adds "Source Code.zip" and "Source Code.tar.gz" links to every release. These are problematic for a few reasons:

1. When I make releases for non-technical audience (a binary build of my software), these links are unwanted. They add clutter and confuse non-developer users.

2. When my repo uses git submodules, these archives lack submodules' source code, which causes confusing compilation errors. I can't even replace them with my own archives that contain complete source code.

3. The source tarballs are not even suitable for distribution of many projects in source code form, because they don't support inclusion of auto-generated files (e.g. ./configure or compiled data files). Auto-generated files shouldn't be under version control — that causes repo bloat and merge pains.

So from my perspective the Source Code links are unnecessary, often undesirable, and even when I'd like some source code links, the auto-generated archives are incomplete and unfit for the purpose.

Please remove these links or at least add an option to disable them.

[MylesBorins]

Hey @kornelski

This is a great idea and something we've talked about internally. We would need to do some research to see if there are any systems that rely on these artifacts that would break in fun and mysterious ways before we could follow through on this.

I've created a feature request internally. We are looking at a number of improvements that we could make to artifacts / assets, but we may not be funding this effort in the immediate future (to set expectations)

[flying-sheep]

Today's xz backdoor shows that allowing to replace those tarballs would be a horrible idea since it would allow malicious actors to sneak in code that doesn't exist in the commit history.

I'm pretty sure a lot of Linux distributions will make it policy to only use tarballs that directly come from tags for security reasons.

[penguin359]

I'm pretty sure a lot of Linux distributions will make it policy to only use tarballs that directly come from tags for security reasons.

I really doubt that will be the case. First of all, there is already pre-existing technology to handle publishing secure tarballs: detached PGP signatures. There are many good projects that do provide these though many more that should be. This is the same cryptography technology that is used to create signed Git commits and tags so it has the same security model, but allows tarballs to be built and distributed securely regardless of what source control system is used to maintain the code by the developers.

Second, there are reasons why tarball contents don't match the repository contents one-for-one. There may be some files that are simply not worth re-distributing for end-users or package maintainers which may not need test datasets, or other development-only files. Also, more importantly, there may be a number of auto-generated files that should not be kept under source control but end-users are not expected to generate on their own such as automake/autoconf files or documentation generated from TeX or Doxygen. These would clutter up the source history, but end-users should not have to worry about installing extra software to generate them after a download.

[vladtcvs]

Source code tarballs shouldn't contain any data, which is not present in git repository. No autogenerated files

[flying-sheep]

What are “detached” PGP signatures?

FYI: the xz backdoor’s tarballs were signed by “Jia Tan”, the account that’s currently believed to be a malicious actor who gained the trust to maintain xz-utils for a while before introducing the backdoor.

[Goatfromcameroon]

test

[bagder]

I'd like to add to this that in our project we upload our generated release tarballs to each release, but GitHub still adds the auto-generates ones at the bottom which then misleads some users pick those instead of the "real" release files listed just above, leading to problems explained above.

[redtide]

I opened a discussion years ago (I still keep the link but it's no longer valid, it was before discussions was added) about this issue but nothing since then (they also created an internal issue about it at that time, so who knows what happened).

Is it that difficult to add an option to disable, at organization/account level, other than per repository, the automatic creation of those mostly useless, confusing and annoying artifacts or is it the ancient Microsoft way of accommodating the majority of new/dumb users who need ready-made baby food? Are they so many that this was not managed/ignored for years?

Shortly after my and other requests I only saw the tar.gz format option disappear on the main page from the green "Code" button (formerly "Download"), which suffers from the same problem.

I heard other developers having to deal with their users about "broken packages" just because they use git submodules and automatic artifacts don't include them.

[redtide]

Suggestion:

Project repository => Settings => General => Features (not Archives, near LFS options could be confusing), something like:

• Automatic package assets
  Creates tar.gz/zip package assets to download from the main page and when tagging new a release

---

If submodules are used by less users then this might be enabled by default unless an account/organization wide setting in:

Account/Org => Settings => Code, planning, and automation => Repository => Repository defaults

same as repository' Features settings above

IMO this should be better disabled by default and add a tooltip somewhere to warn one time only new users that that option exists, otherwise a "Using submodules? You can disable this org or repo wide here and there" tooltip.

[xan2622]

Hi.
Is it still being considered to add an option to disable these extra downloads (Source Code.zip and Source Code.tar.gz) that are sometimes unwanted?

[dboeger1]

I hate to dredge up what appears to be an old, somewhat ignored topic, but I stumbled on this while having similar issues, and would really like to have the option to at least hide those artifacts. In DevOps/automation contexts, having control of source archive naming, publishing, and contents is crucial. While having these extra artifacts certainly doesn't block my ability to upload my own, it's just really annoying to see seemingly duplicate source archives with different names and have to explain to users that I have no clue if the GitHub one works with my code.

[ARogueOtaku]

Hey, I recently tried using the Git release feature for the 1st time and immediately noticed this. I see the original answer was back in Oct 2021 which was 2+ years ago. Were there any updates on this since then?

[redtide]

We would need to do some research to see if there are any systems that rely on these artifacts that would break in fun and mysterious ways before we could follow through on this.

Is it that difficult to make this feature a repository settings option so it wouldn't cause problems to anyone else?

but we may not be funding this effort in the immediate future (to set expectations)

More than 3 years now.

[mcuee]

We have to put the same note for our releases.
https://github.com/libusb/libusb/releases/tag/v1.0.27
https://github.com/libusb/libusb/releases/tag/v1.0.26

Note:
*.tar.bz are our official release files, these are proper release tarballs including configure.

*.tar.gz and .zip are something GitHub generates, unfortunately we haven't found a way to disable them. They are just a git snapshot, without e.g. configure.

*) https://github.com/orgs/community/discussions/6003

[TheCarpetMerchant]

@MylesBorins Can you update us on this ? A simple option to disable the generation would be sufficient for basically everyone here.

[adamlui]

I just published my first release in a monorepo and immediately noticed how confusing the auto-attached files are.

@mcuee your solution is so elegant, I immediately implemented it and it is beautiful workaround!

[TheCarpetMerchant]

You're absolutely hilarious, I'll be following for more !

[userdocs]

Listen, you people are thinking about this all wrong, instead of being critical of this clearly elegant and beautiful solution we should be doubling down here, expanding it's potential to be more eleganter.

So I propose a spec of sorts, the most helpful note possible that can be created to aid the end user. I hope you understand the potential here.

The first suggestion I propose for this spec v0.0.1 is related to accessibility. Not everyone reads English, an ugly oversight if I do say so myself.

So I have translated the note into every possible language and suggest all notes to be included are translated to all known and unknown languages.

Here is my example: https://github.com/userdocs/test/releases/tag/v1.33.7

https://gist.github.com/userdocs/4e83e157d4cf57ca981b8e823dac821a

[adamlui]

@userdocs I got thousands of users in mere weeks which my internationalization attempts likely played at least a small part in, so your attempts to make me feel bad for turning a negative into a positive thus potentially captivating a wider audience is failing btw

[redtide]

you guys pay your attention to a troll.

[adamlui]

@redtide what troll do you speak of?

[mcuee]

Because he's not presenting it as a solution or workaround, just highlighting that he had to do a dumb thing due to Github not giving us control over the release feature assets.

I do not understand the thumbdowns towards the comments by @adamlui. Maybe it is just due to the different understandings of the word workaround.

For sure it is not elegant and it is not a solution. But we can not do much -- so we provide the note to let the user know which release tarball to download. You can call it sort of a workaround as well.

In the end, we all hope that github can provide the real solution so that we do not need to add the note in the future. For example, the suggestion to make this feature a repository settings option is a good solution to me.

[adamlui]

Yes but the v-spacing is awkward and color brings unnecessary over-emphasis is why I avoid them

[adamlui]

GitHub designers added the coloring after I added notes/tips to my chatgpt.js.org and distinct coloring to sections/shields btw (but awkwardly added v-spacing so it doesn't look good like before).

They are one of my closest followers, frequently releasing "updates" after my innovations (another example, after I released my first ChatGPT Chrome extension, they copied my popup.html design for the re-design of upper-right corner button menu, with the shape and horizontal separators)

[adamlui]

Another example, after I added search to chatgpt.js.org, they overhauled their search engine and even redeisgned their website header row

[redtide]

I do not understand the thumbdowns towards the comments by @adamlui. Maybe it is just due to the different understandings of the word workaround.

because attracts people like you wasting time and log talking about a ridiculous workaround while other people like me waits a solution from some years.
Then maybe some GH operator comes here like "let's see how is going that discussion... ah nice, they are focused on a stupid workaround, screw it."

[adamlui]

@redtide you can't even see, if a decision maker finds a workaround "stupid", let alone discussion is popping off like I make it, they will more likely address the problem

[rashed9810]

Can anyone please tell me how I want to be a pro coder ?

[redtide]

you are doing good, by doing offtopic questions in the wrong place.

[peter-mccann]

I went down a rabbit hole, But I thought I'd share my findings anyway.

If you have made it this far congratulations. (please read everything)
If one is not opposed to using the github cli or api in a script here WAS a possible workaround.

Github CLI release
GitHub API release

gh release delete-asset -y

or using the API directly from github discussions
The following returns JSON output
gh api repos/owner/repo/releases/tags/v1.0.0
gh api -X DELETE

Note: This does require you to login to GH using a Personal Access Token as shown below
Note: Powershell does not have a way to redirect input into a command using "<" we are forced to use cmd.exe
& cmd.exe /c "gh auth login --with-token < .\PAT.txt"
Note: From Unix
/usr/bin/gh auth login --with-token < ./PAT.txt

Verify login status
gh auth status

Unfortunately, The sourceCode.zip and sourceCode.tar.gz are not considered assets even though they are listed on the UI as Assets. They don't show up in the .assets[] json array when querying the releases
gh api repos/ORG/REPO/releases/tags/vX.Y.Z
"assets": [],

[ckreibich]

It's been a couple of years and the original answer didn't offer any solutions, so I wanted to ask whether the planning for this has changed on Github's side? The pattern of "please use our tarballs, not the auto-generated ones" seems to have only become more pervasive since.

[babakfp]

Microsoft owns GitHub. So, don't expect anything! This is the same story. All of their projects slowly get fewer and fewer updates and fixes and after some point, they completely abandon them.

[zerefdev]

Bump

[vallerydelexy]

bump

[usmankhawar22]

We are getting around 100 Mbs of zip and tar file per releases, which is chocking our 10GB storage limit.

[MrGadget1024]

I need this too...just a setting in GitHub we can turn off so they're not published in the release.

[mloiseleur]

We need this too.
Just a setting to be able to turn it off when it's not relevant.

[mnlx]

Bump!

[potus-barret]

     |     |     
  X  |  -  |  -  
 ____|_____|_____
     |     |     
  -  |  -  |  -  
 ____|_____|_____
     |     |     
  -  |  -  |  -  
     |     |