-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Makefile does not support released archive without dotgit directory #3645
Comments
The source tarball is something github automatically generates on the fly and is not controlled by us. Can you clone the repo instead? |
(docs: https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives -- not controlled by us) We actually already inject the release info into checked in sources so if you |
The context for the distro packaging is intentionally controlled (no internet access, local compiler). So, I am already struggling with the imports, they all must be already packaged in the distro (I will start with an vendored approach just to divide the work). About the released package; sure, the dynamically generated archive are not usable. I see that some projects do provide source packages next to the github links in the list of artefacts (for instance https://github.com/containers/toolbox/releases ). Is that a feasible approach? Of course, I could do a manual packaging of the tagged "git clone" output into a tgz archive but that feels a bit old school in term of automation :-) |
I'd rather special case the makefile to not fail the git status on release tagged commits (... somehow ...) than add another release artifact to maintain and host that won't even be complete for your purposes anyhow (since it will not have vendor).
Sure, but you had to download the source archive somehow, are you not able to download an actual repo clone instead? The machine that has internet access to tar up a git clone without any changes on our end. |
This is normal, many projects require you to supply additional information like version and commit over a side channel.
The tarballs exported by git are predictable (they tried to change the format, but had to revert the change after outcry...)
Note: You might also want to "vendor" all dependencies. For instance, Buildroot does this for you with go packages: https://buildroot.org/downloads/manual/manual.html#_infrastructure_for_go_packages KIND_VERSION = 0.23.0
KIND_SITE = $(call github,kubernetes-sigs,kind,v$(KIND_VERSION))
KIND_LICENSE = Apache-2.0
KIND_LICENSE_FILES = LICENSE
KIND_GOMOD = sigs.k8s.io/kind
Where this new source tarball also includes the "vendor" directory. The LICENSE file only differs in typography, maybe a version thing ? @@ -1 +0,0 @@
-
@@ -182 +181 @@
- boilerplate notice, with the fields enclosed by brackets "[]"
+ boilerplate notice, with the fields enclosed by brackets "{}"
@@ -190 +189 @@
- Copyright [yyyy] [name of copyright owner]
+ Copyright {yyyy} {name of copyright owner} When compared with http://www.apache.org/licenses/LICENSE-2.0
Most packaging systems still work with tarballs and patches, rather than using git when building. Some systems, like But using |
@ehdis you need to also use the
|
Note: not everyone bothers with commit information, since it is readily available from the tags anyway... Example: https://github.com/buildroot/buildroot/blob/master/package/docker-engine/docker-engine.mk -X $(DOCKER_ENGINE_GOMOD)/dockerversion.GitCommit="buildroot" \
-X $(DOCKER_ENGINE_GOMOD)/dockerversion.Version="$(DOCKER_ENGINE_VERSION)" i.e. there is a dummy text instead |
There is a size difference, if storing the .tar.gz (git archive) or the .bundle (git bundle):
Due to the git repository storing all history too, but the tarball only storing the files. |
JFI: the Makefile uses git commands but the release package does not provide intentionally the git subdirectory.
Should the release process inject such informations into the Makefile (as fallback / default values)? Reproduce it with:
-> gitCommit gitCommitCount vars are empty
Why the release package? I'm trying to package kind for a distro to put it into a repository and distribute it to all workstations, and the rule is to use the "official" releases.
Thanks!
The text was updated successfully, but these errors were encountered: