Signing is not setup for these repositories. It seems they haven't been updated
since before trust was added since their previous Makefile metadata (which was
translated in build.yml) did not contain `NOTRUST=1`.
Signed-off-by: Ian Campbell <ijc@docker.com>
By running:
./scripts/update-component-sha.sh --image linuxkit/alpine ad35b6ddbc70faa07e59a9d7dee7707c08122e8d
Signed-off-by: Ian Campbell <ijc@docker.com>
This was done with the following "script":
git rm pkg/{auditd,binfmt,init}/Makefile
sed -e 's/IMAGE=/image: /g' -i pkg/*/Makefile
sed -e 's/NETWORK=1/network: true/g' -i pkg/*/Makefile
sed -e 's/ARCHES=x86_64/arches:\n - amd64/g' -i pkg/*/Makefile
sed -e '/DEPS:\?=/d' -i pkg/*/Makefile
sed -e '/ARCHES=SKIP/d' -i pkg/node_exporter/Makefile
sed -e 's/include \.\.\/package.mk//g' -i pkg/*/Makefile
sed -e '/^$/d' -i pkg/*/Makefile
git mv pkg/node_exporter/Makefile pkg/node_exporter/build.yml-skip
for i in pkg/*/Makefile ; do git mv $i ${i%Makefile}build.yml ; done
and manual update of pkg/Makefile.
Signed-off-by: Ian Campbell <ijc@docker.com>
tools/alpine and tools/guestfs are omitted since they do not currently use
pkg/package.mk and do their own thing. Slightly hacky arrangements are made for
these. Note that previously they were only recursed into for their default
target (push) and that behaviour is retained.
Signed-off-by: Ian Campbell <ijc@docker.com>
Current versions of Docker complain:
Sending build context to Docker daemon 5.12kB
Step 1/4 : FROM linuxkit/guestfs@sha256:62e810869e83dabe04af7ac8fcd81d9f177d986a3424dcb9c4eb5439993c962f
...
Successfully tagged linuxkit/mkimage-gcp:736880776838c8f41c081276d9c017ae6adbf1bb-amd64
Tagging linuxkit/guestfs@sha256:62e810869e83dabe04af7ac8fcd81d9f177d986a3424dcb9c4eb5439993c962f as linuxkit/guestfs:aecc40bf84ce4f4238e06934c46d7cc570a39eed@sha256:62e810869e83dabe04af7ac8fcd81d9f177d986a3424dcb9c4eb5439993c962f
refusing to create a tag with a digest reference
../../pkg/package.mk:82: recipe for target 'tag-y' failed
Just use the digest for now. Perhaps someone will have time to fixup this build
properly at some point.
Make the same change to test/pkg/ltp.
Signed-off-by: Ian Campbell <ijc@docker.com>
Using explicit targets is cleaner and easier to follow.
Also add `forcepush` to pkg and test/pkg and make `push` explicit.
The `dirs` phony was non-existent in all three cases. Likewise `$(DIR)` wasn't
used in that way in pkg or test/pkg and is nolonger used in that way in tools.
Finally, `clean` was bogus in all cases (tools cleaned a thing which never
exists and pkg and test/pkg were a syntax error).
Signed-off-by: Ian Campbell <ijc@docker.com>
This is a bit gross, but hopefully this script will be written in go sooner
rather than later and in the meantime this avoids the need to install yet
another tool on user's systems (and get it into brew etc).
Checkin the result of `go:generate` for now. Once there are no more users of
push-manifest.sh it can be moved alongside the go code (if it hasn't been
rewritten in go along the way).
Signed-off-by: Ian Campbell <ijc@docker.com>
This implements the proposal in #2564 and converts a handful of representative
or especially interesting (from a build PoV) packages to use it.
For now those pkg/* affected get a stub-`Makefile`, once all packages are
converted then `pkg/Makefile` can be adjusted and those stubs can be removed.
For now only `pkg/package.mk`'s functionality is implemented. In particular:
- `push-manifest.sh` remains a separate script, to enable calling it on systems
with just the LinuxKit tools installed arrange to install it under a less
generic name.
- `kernel` and `tools/alpine` do not use `pkg/package.mk` and those cases are
not yet fully considered/covered.
I have updated the documentation assuming that the existing uses of
`pkg/package.mk` will be removed quite soon in a follow up PR rather than
trying to document the situation which results after just this commit.
Due to `cmd/linuxkit` now gaining a library the build needs adjusting slightly to
allow both `make bin/linuxkit` and `go build` to work.
`go vet` has forced me to write some rather asinine comments for things that
are rather obvious from the name.
Signed-off-by: Ian Campbell <ijc@docker.com>
These packages include the wireguard tools which need to be
updated due to the wireguard kernel bump in:
43db718f14 ("wireguard: version bump").
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
In particular also fix the wireguard test whose kernel
tag hasn't been updated for quite some time...
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Unfortunately some options (such as enabling dynamic registration of
initializers) can only be enabled by a `--config foo.yaml` argument.
Furthermore some command-line options (such as the kubernetes version)
cannot be used in combination with the config file.
This patch checks for a supplied /etc/kubeadm/kubeadm.yaml and uses
it if it exists, otherwise it falls back to the original command-line.
Note it is safe to use the `--skip-*` options in combination with the
`--config` option.
Signed-off-by: David Scott <dave.scott@docker.com>
It is possible to get rebooted halfway through the init process, after key
files like `/etc/kubernetes/kubelet.conf` have been created but before full
cluster setup is complete or networking is applied.
Right now the idempotency of kubeadm (or backing out from this half-way state
and resuming the initialisation) is not something I have investigated. By
dropped stamps before and after at least the situation will be somewhat
detectable/diagnosable so the user can e.g. nuke their persistent disk and
start again.
Signed-off-by: Ian Campbell <ijc@docker.com>
If a stamp file is present in the metadata then untaint.
This is useful for dev environments where you only want to start a single vm.
The construction of the metadata becomes a little more complex to produce
correct json syntax now that there are two (independent) possible options.
Likewise the kubelet.sh script now takes the presence of /var/config/kubeadm
(rather than /var/config/kubeadm/init) as the signal to use the more structured
setup, since we may now have /var/config/kubeadm/untaint-master but not
/var/config/kubeadm/init so would otherwise end up passing the contents of
`/var/config/userdata` (something like `{ "kubeadm": { "untaint-master": "" }
}`) to `kubeadm` and confusing it enormously.
Signed-off-by: Ian Campbell <ijc@docker.com>
