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: 42 comments 45 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.
-
|
Source code tarballs shouldn't contain any data, which is not present in git repository. No autogenerated files |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
test |
Beta Was this translation helpful? Give feedback.
-
This has been a few years, can an updated be provided? An option to solve the usability issue while preserving the integration with dependencies would be to add a config on the release object to display/hide the default Source Code zip and tar files. This would have minimal impact and could be backwards compatible because it would only affect the UI not any APIs |
Beta Was this translation helpful? Give feedback.
-
|
Please just add a setting to disable these links. This is very problematic for projects that use build systems that require bootstrapping (such as autotools). Right now, releases create links to the repository's exports without the bootstrapped build system completely confusing anyone looking at them. |
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. |
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
You're absolutely hilarious, I'll be following for more ! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
you guys pay your attention to a troll. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Can anyone please tell me how I want to be a pro coder ? |
Beta Was this translation helpful? Give feedback.
-
|
you are doing good, by doing offtopic questions in the wrong place. |
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.
-
|
Yo Github, this would be such a good holiday present to your community! And you have well over a week to do it still. What's not to like? |
Beta Was this translation helpful? Give feedback.
-
|
All github has to let us do is hide it from view. That's it. It will break nothing and has 0 risk to them to just make it a cosmetic change. If you tell them to remove the actual assets you will probably break a silly amount of projects using the assets. This is why they will never remove them but a cosmetic change to allow excluding these auto generated assets them from view in the website will break nothing. Something like this you toggle in the repo settings, where if you have no custom assets, you see nothing. Before After |
Beta Was this translation helpful? Give feedback.
-
|
I agree, some flag on the release config that lets me hide the default assets while displaying any custom ones added to the release. |
Beta Was this translation helpful? Give feedback.
-
|
Really, no movement on this for nearly 4.5 years? @MylesBorins ? Is this possible on enterprise? |
Beta Was this translation helpful? Give feedback.
-
|
Need this! Working on a software where the source code is not meant to be public alongside the executable release... |
Beta Was this translation helpful? Give feedback.
-
|
Copilot AI returned this response when I requested a feature enhancement. (I submitted the ticket anyway) perhaps this will get some movement. Currently, GitHub does not provide a way to disable or delete the automatically generated source code archives (sourceCode.zip and sourceCode.tar.gz) that are included with releases. These archives are automatically created for every release based on the associated Git tag and are not considered part of the assets[] array when querying the release data via the GitHub API. If you want to avoid these files being listed as part of your release, you could consider the following workarounds: Custom Release Assets: Instead of relying on the auto-generated source code archives, you can manually upload your own release assets. This can be done through the GitHub UI or programmatically using the Release Assets REST API. Clarify in Release Notes: If the presence of these auto-generated files is causing confusion, you can add a note in your release description to clarify which files are the intended assets for your release. Unfortunately, there is no built-in feature to disable or delete these auto-generated files at this time. If this is a critical need for your workflow, I recommend sharing your feedback directly with GitHub via the GitHub Feedback form. This ensures that your request is considered for future updates. |
Beta Was this translation helpful? Give feedback.
-
|
I build and push my own binaries and it makes no sense why supplemental source code would be pushed along side them. |
Beta Was this translation helpful? Give feedback.
-
|
When using the releases as a company, providing "source code" to end users is often highly inappropriate. Please add a way to hide or remove these. |
Beta Was this translation helpful? Give feedback.
-
|
@tuves Any chance of someone picking this up? |
Beta Was this translation helpful? Give feedback.
-
|
so slowly about the issue. I met the same question. please ..... |
Beta Was this translation helpful? Give feedback.
-
|
I've re-raised it, as clearly no-one looks at older discussions... https://github.com/orgs/community/discussions/158761 |
Beta Was this translation helpful? Give feedback.
-
|
If I can't turn this off I can't use Git Hub to release betas for my game as it would contain undecrypted assets which would go against the licenses of said assets. There should be a way to only release the files we select without it autoincluding raw data. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
(edit: My comment only regards repositories with actual source code. I have no opinion on non-source-code repositories.)
This site holds git repositories. A release is, in particular, a release of that version of the repository. You can caution non-technical users to avoid the source tarballs.
That's a bug with your repository. It can't "use git submodules". The repository must be usable independently of the VCS it uses (in your case, git). Fix your repo. Ways to do this:
The tarballs contain a copy of your repository. Everything people need in order to build and use the code should be in there. If a file needs to be auto-generated on the build machine, then of course it shouldn't be in the repository; the person downloading it will generate it. With your example, the person downloading your repository will run the autoconf tool to obtain a
I would ask @MylesBorins and other GitHub people to specifically decline doing this, even as option, because it encourages mis-management of repositories, and a mis-perception of a repository maintainer's responsibility when making releases. |
Beta Was this translation helpful? Give feedback.
-
The fact that GitHub specifically recommends things such as Issue Only Repositories shows that the site is for more than just holding "git repositories". That may be the primary purpose, but there are many use cases where it makes sense to not force these to exist. |
Beta Was this translation helpful? Give feedback.
-
|
@ReedCopsey : Ok, fair enough, but - such repositories would probably not have releases, right? |
Beta Was this translation helpful? Give feedback.
-
|
No - releases are the recommend way to close issues and tie them to a release (managed separately for code) in those repositories. That's pretty much my exact pain point at the moment. The releases make sense for managing issues, but the stupid "release artifact" files are pretty awful for end users looking at them. |
Beta Was this translation helpful? Give feedback.
-
|
I see. Well, I've qualified my comment to only refer to repositories with actual source code. |
Beta Was this translation helpful? Give feedback.
-
|
My actions only run when sings parts of my repo are updated. Those parts create two sets of zips (software and STLs) The rest of the repo is guidance, and internal files that I don't really want users downloading. It really is a simple request. Allow for the release to be configured to show those links or not. I can add custom files, zips etc. Why can't I hide the default? |
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)