-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release tarballs with bundled git submodules #274
Comments
Thanks, uploading static assets for releases which contain all sources, including submodules makes sense. Do you know if there is a way to do this automatically in GitHub? |
I'm not familiar with GitHub, but expect it to be possible. |
Looking at documentation and searching for prior art on this platform yielded #279, but I don't know how to test it. |
Thanks a lot, looks nice! I'll discuss this with my colleague just in case. I'm 90% sure we will merge this. |
Contrary to auto-generated release tarballs, this one includes all submodules such that operating system infrastructure gets a complete source tree wihtout having to fetch submodules themself. Add "-full" between name and version to distinguish the two tarballs. The token needs read/write permissions to clone the repository and upload assets to existing releases, respectively. Fixes web-eid#274 Signed-off-by: Klemens Nanni <[email protected]>
Contrary to auto-generated release tarballs, this one includes all submodules such that operating system infrastructure gets a complete source tree wihtout having to fetch submodules themself. Add "-full" between name and version to distinguish the two tarballs. The token needs read/write permissions to clone the repository and upload assets to existing releases, respectively. Fixes web-eid#274 Signed-off-by: Klemens Nanni <[email protected]>
Contrary to auto-generated release tarballs, this one includes all submodules such that operating system infrastructure gets a complete source tree wihtout having to fetch submodules themself. Add "-full" between name and version to distinguish the two tarballs. The token needs read/write permissions to clone the repository and upload assets to existing releases, respectively. Fixes web-eid#274 Signed-off-by: Klemens Nanni <[email protected]>
Contrary to auto-generated release tarballs, this one includes all submodules such that operating system infrastructure gets a complete source tree wihtout having to fetch submodules themself. Add "-full" between name and version to distinguish the two tarballs. The token needs read/write permissions to clone the repository and upload assets to existing releases, respectively. Fixes web-eid#274 Signed-off-by: Klemens Nanni <[email protected]>
Contrary to auto-generated release tarballs, this one includes all submodules such that operating system infrastructure gets a complete source tree wihtout having to fetch submodules themself. Add "-full" between name and version to distinguish the two tarballs. The token needs read/write permissions to clone the repository and upload assets to existing releases, respectively. Fixes web-eid#274 Signed-off-by: Klemens Nanni <[email protected]>
Would you consider uploading static assets for releases which contain all sources, i.e. submodules?
Systems like OpenBSD ports have no network access during package building, so additional sources submodules need to be fetched and moved into place manually.
A single tarball from upstream containing all neccessary upstream code would simplify that process.
Alternatively, package maintainers like me could checkout git sources recursively for a release and vendor tarballs for operating system package infrastructure to use, but albeit simplifying the ports/package process, it also adds yet another layer of indirection and trust.
The text was updated successfully, but these errors were encountered: