The main reason for bumping Vault's version is because 1.2.3 is not
compatible with the config parameter `disable_iss_validation`, which is
needed for accommodating the future tests [1] that rely on bound tokens
and static tokens.
For context, Vault 1.2.3 was released on Sep 9, 2019 [2] but
`disable_iss_validation` was only added on July 21st, 2020 in Vault
1.5.0.
Due to a breaking change that happened in Vault 1.5.0 [3] in which Vault
started loading the pod's token instead of using the same token (to be
reviewed) for authenticating. An alternative solution could have been to
prevent the service account from being mounted to the pod, but I figured
that having the two service accounts separated is a better practice.
[1]: https://github.com/cert-manager/cert-manager/pull/5502
[2]: https://github.com/hashicorp/vault/commit/c14bd9a2
[3]: https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#150
Signed-off-by: Maël Valais <mael@vls.dev>
In #5473 we saw a user being confused by devel's continued existance.
No bazel stuff will work any more and there's value in having just one
place where our e2e setup scripts are located, and that's now in `make`.
It was considered that we might keep some of these scripts but
converting them to call make commands, but that might be a lot of work
for minimal reward.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
This adds multiple retries on every attempt we make to use curl, which
should help to reduce flakes. Uses a $(CURL) variable where possible so
that we have the same invocation everywhere.
Also switches to using the more verbose curl arguments, in an attempt to
make it easier to reason about how curl is configured.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
This is needed because go and other tools will ignore directories
starting with "_" or "." but would treat a dir called "bin" as a regular
directory.
This in turn meant that when we vendored Go in bin, these tools would by
default scan the whole stdlib included with the bundled vendored go.
See https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns for details
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
By specifying a different kind config that does not use an etcd flag that was only add in later etcd versions
Signed-off-by: irbekrm <irbekrm@gmail.com>
The default value for --acme-http01-solver-image was off.
quay.io/jetstack/cert-manager-acmesolver:v1.7.0-beta.0-260-gd0abb71ef0a78d
<-------------------------------------->
incorrect
cert-manager-acmesolver-amd64:v1.7.0-beta.0-260-gd0abb71ef0a78d
<--------------------------->
correct
Signed-off-by: Maël Valais <mael@vls.dev>
Not sure how the end-to-end tests were ever able to run previously. My
guess: the sample-external-issuer end-to-end suite is disabled.
Signed-off-by: Maël Valais <mael@vls.dev>
I had removed GOFLAGS because I had added -X directives (for filling in
AppVersion and AppGitCommit) to GOFLAGS. It seems like go tool link does
not care whether the symbol exists or not, so it seems OK to use the
same GOFLAGS to build the samplewebhook and pebble even though the -X
directives don't make sense for them.
Signed-off-by: Maël Valais <mael@vls.dev>
When checking how User-Agent headers would differ from v1.7.1 to
v1.8.0, The User-Agent looked off:
cert-manager-issuers/v1.8.0 (linux/amd64) cert-manager/
The ending "/" should be followed by the git commit hash. It seems like
we forgot to port what Bazel does to fill AppVersion, AppGitCommit, and
AppGitState. This commit adds this feature to the Makefile. The
User-Agent should now look like this:
cert-manager-issuers/v1.8.0 (linux/amd64) cert-manager/9dd5f6c85fde2c3ed58cd6c9e465bb5a4c1ca2b2
<----->
This part depends
on the component.
Signed-off-by: Maël Valais <mael@vls.dev>
These two targets are not used by our end-to-end tests meaning that they
may either be broken or removed in the future.
Signed-off-by: Maël Valais <mael@vls.dev>