the bundles target is incorrect in a release since it won't generate
release metadata which we require when publishing a release
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
If we're in the middle of a cert-manager release we'll have a git tag
created for that release, but won't have a GitHub release created yet.
That means that an attempt to download old CRDs for our versionchecker
test will fail for that version, with a 404 error.
An alternative approach would be to use the GitHub API to query for
existing non-draft releases - but that introduces a new point of failure
whereby we can easily hit a rate limit, or else introduces the need for
a GitHub API token.
The GitHub API also has the issue that it doesn't present every release
in one API call, which complicates fetching releases using curl and uses
even more rate-limit capacity.
The approach here is simple; we ignore tags for which the release 404s,
download manifests for which the release gives a 200, and bubble up any
other errors.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
I think having a separate file for storing the various kind image
digest isn't necessary. From now on, make/cluster.sh is the "source of
truth" for everything related to kind. If you would like to see the
image that is going to be used for creating the kind cluster, you can
run:
make/cluster.sh --show-image
To self-update the digests with the latest available digests, run:
make/cluster.sh --update-images
Signed-off-by: Maël Valais <mael@vls.dev>
The fixed CIDR isn't necessary anymore since the makefile figures the
ClusterIP dynamically. This change also enables you to run
make/cluster.sh with an existing kind cluster.
Signed-off-by: Maël Valais <mael@vls.dev>
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>
Previously, the XML was saved to $ARTIFACTS, which was not picked up by
the Prow UI. The XML files must be of the form: junit_*.xml.
This format is required by our Spyglass configuration (Spyglass is the
name the Prow UI) [1].
[1]: https://github.com/jetstack/testing/blob/d04c4641f/config/config.yaml#L80-L81
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>
This is to work around the fact that binaries in hostPath-mounted
directories cannot be executed even if the permissions are correct.
Signed-off-by: Maël Valais <mael@vls.dev>
This makes it easier to tell when a build was made by the makefile
workflow and therefore to adjust `cmrel publish` to adapt to changes
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
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>
Otherwise, the target 'e2e-setup' fails. At least, that gives people a
chance to have some of the end-to-end tests pass. I added a warning to
let people know that they can still force using CRI_ARCH=amd64, which is
possible on Docker Desktop thanks to the QEMU emulation that kicks in
when a container with the arch amd64 tries to execute.
Note that this work around does not work on Colima at the moment.
Signed-off-by: Maël Valais <mael@vls.dev>
It seems like Ginkgo isn't running from the root of the repository, that's why
it can't find binaries, e.g., bin/tools/etcd.
Signed-off-by: Maël Valais <mael@vls.dev>
I had written instructions that would show up when you don't have one of
the mandatory system tools such as go or jq. After some feedback, I
decided to remove these instructions since we are concerned that these
instructions may become out of date.
Signed-off-by: Maël Valais <mael@vls.dev>
