No way to disable auto-generated source code zip links #6003
-
GitHub automatically adds "Source Code.zip" and "Source Code.tar.gz" links to every release. These are problematic for a few reasons:
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. |
Beta Was this translation helpful? Give feedback.
Replies: 24 comments 37 replies
-
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) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Suggestion: Project repository => Settings => General => Features (not Archives, near LFS options could be confusing), something like:
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. |
Beta Was this translation helpful? Give feedback.
-
Hi. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
Is it that difficult to make this feature a repository settings option so it wouldn't cause problems to anyone else?
More than 3 years now. |
Beta Was this translation helpful? Give feedback.
-
We have to put the same note for our releases. Note: *.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 |
Beta Was this translation helpful? Give feedback.
-
@MylesBorins Can you update us on this ? A simple option to disable the generation would be sufficient for basically everyone here. |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
I do not understand the thumbdowns towards the comments by @adamlui. Maybe it is just due to the different understandings of the word For sure it is not 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 |
Beta Was this translation helpful? Give feedback.
-
Can anyone please tell me how I want to be a pro coder ? |
Beta Was this translation helpful? Give feedback.
-
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) Github CLI release gh release delete-asset -y or using the API directly from github discussions Note: This does require you to login to GH using a Personal Access Token as shown below Verify login 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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
We are getting around 100 Mbs of zip and tar file per releases, which is chocking our 10GB storage limit. |
Beta Was this translation helpful? Give feedback.
-
I need this too...just a setting in GitHub we can turn off so they're not published in the release. |
Beta Was this translation helpful? Give feedback.
-
We need this too. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
Please allow this! For one of my repos, adding "source code" is misleading at best. |
Beta Was this translation helpful? Give feedback.
-
Any update? |
Beta Was this translation helpful? Give feedback.
-
I wholeheartedly support the suggestion I found a little workaround that at least saves space:
This will create empty "source code" zips. |
Beta Was this translation helpful? Give feedback.
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)