In a number of tests, the underlying storage backend interaction will
return the revision (logical clock underpinning the MVCC implementation)
at the call-time of the RPC. Previously, the tests validated that this
returned revision was exactly equal to some previously seen revision.
This assertion is only true in systems where no other events are
advancing the logical clock. For instance, when using a single etcd
cluster as a shared fixture for these tests, the assertion is not valid
any longer. By checking that the returned revision is no older than the
previously seen revision, the validation logic is correct in all cases.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
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>
