Makefile does not support released archive without dotgit directory about kind

[BenTheElder]

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?

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).

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).

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.

[BenTheElder]

The source tarball is something github automatically generates on the fly and is not controlled by us.

Can you clone the repo instead?

[BenTheElder]

(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 go install sigs.k8s.io/[email protected] it will work, but the makefile is expected to be used from a local clone currently.

[ehdis]

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 :-)

[afbjorklund]

This is normal, many projects require you to supply additional information like version and commit over a side channel.

make kind COMMIT=0296c52b38a6bb5ccdcbcf4e57f0ba79415e6ff2 COMMIT_COUNT=v0.23.0

The tarballs exported by git are predictable (they tried to change the format, but had to revert the change after outcry...)

b8ea6665bc37a34de0a6fe7592fb8ae376847e1c93fc5d6377140a98c1aa6a55  kind-0.23.0.tar.gz

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

# Locally calculated
sha256  95a6bd8c1776afe8136d5919235f2b34ea217ec81c18b38d206cedb6fff2928f  kind-0.23.0.tar.gz
sha256  b40930bbcf80744c86c46a12bc9da056641d722716c378f5659b9e555ef833e1  LICENSE

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

---

Can you clone the repo instead?

Most packaging systems still work with tarballs and patches, rather than using git when building.

Some systems, like brew, give you the option of either - you can use something like --HEAD.

But using git archive is "normal"

[afbjorklund]

@ehdis you need to also use the -J flag with curl, in order to get the correct filename on the download

content-disposition: attachment; filename=kind-0.23.0.tar.gz

[afbjorklund]

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

[afbjorklund]

There is a size difference, if storing the .tar.gz (git archive) or the .bundle (git bundle):

2,0M	kind-0.23.0.tar.gz
`13M	kind-0.23.0.bundle

Due to the git repository storing all history too, but the tarball only storing the files.