If a staging repo has .gitattributes files containing the `export-subst`
attribute ([example](b6c06a95d7/staging/src/k8s.io/client-go/pkg/version/.gitattributes)), then git expands the specified placeholders
when git archive is used.
When a published repo is downloaded from GitHub, GitHub does a
"git archive" under the hood. This means that the placeholders get
replaced by their relevant values. This type of "git archive"
application sometimes leads to undesired values. See the example below.
- In client-go, [line 59 in `pkg/version/base.go`](b6c06a95d7/staging/src/k8s.io/client-go/pkg/version/base.go (L59))
is expanded on a git archive. This line is needed as a fallback to
inject k8s version info for client-go when this info is not provided
via ldflags during builds.
- However, when k/client-go is vendored, the line gets expanded to _the
commit of the project vendoring client-go_ -- which is not helpful at
all! This also means that the vendored client-go will now contain
different (expanded) commit shas for different projects.
- To ensure reproducibility of source, this commit helps remove
the .gitattributes files before publishing the staging repos.
Additionally, when client-go is used as a library, we don't care about
the line being expanded to inject version info so it is also safe to
remove these files.
When tests attempt to validate behavior in the case that a client asks
for a resource version that is "too large" for the underlying storage,
the previous implementation would simply add 1 to the latest revision
seen. This is only appropriate for storage backends that
a) provide a continuous monotonic logical clock
b) have no other events occurring while the test runs
For instance, when using a singe etcd backend as a shared fixture for
these tests, adding 1 to a previously-seen revision is not suffcient to
ensure that the resulting revision is "too large". By instead using the
largest possible integer value, we can be certain of this.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
This should fix the following error when running
./hack/update-generated-stable-metrics.sh:
'go get' is no longer supported outside a module.
To build and install a command, use 'go install' with a version,
like 'go install example.com/cmd@latest'
For more information, see https://golang.org/doc/go-get-install-deprecation
or run 'go help get' or 'go help install'.
Using `go get` to download gopkg.in/yaml.v2 package into
KUBE_EXTRA_GOPATH directory no longer works. Interestingly, main repo
already has gopkg.in/yaml.v2@v2.4.0, same version that was installed by
that go get.
I guess that GOPATH with multiple elements no longer works either,
and since this code was the only user of KUBE_EXTRA_GOPATH, let's remove
it as well.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This fixes the following error:
> test/integration/apimachinery/watch_restart_test.go:232:5: call to (*T).Fatalf from a non-test goroutine
Update: the previous fix (commit 1ce55e3afe that uses panic)
looks way too severe; it seems it is enough to call t.Errorf and return
from goroutine. The test will time out and fail anyway.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
