This workflow file was written speculatively prior to our migration and
it seems to be failing during code checkout. Other workflow files use
the full URL to point to the Forgejo repository, and the latest action
is now v7.0.1.
Additionally:
- We need to have node installed as it's a dependency to run the
checkout action.
- I broke one of the azure tests when I fixed upload failing due to the
gallery API silently changing
- Time marched on and needed freezing since Fedora 42 EOLd
Signed-off-by: Jeremy Cline <jeremycline@microsoft.com>
Recently there was a regression in Pika, and it would generally be nice
to use distribution packages for most of our dependencies. Since the
image tester is already committing similar crimes I think it's fine for
the uploader, too.
Right now we only pull in the Google SDK bits from PyPI, as well as the
Azure compute module from there since the Azure CLI pins an ancient
version.
Signed-off-by: Jeremy Cline <jeremycline@microsoft.com>
Somewhat recently, Azure images started failing to upload, crashing when
calling azure_compute_client.gallery_images.begin_create_or_update with
a server-side error of "HttpResponseError: (InvalidParameter) Required
parameter 'galleryImageVersionName' is missing (null)."
It _seems_ like it no longer allows updating a gallery image (even if
there are no actual updates happening, it just declares it as it always
was) with features that don't include a version within that gallery
where the feature is first enabled.
Signed-off-by: Jeremy Cline <jeremycline@microsoft.com>
SDKs have been moving away from bundling all the API versions so this
isn't going to keep working.
Signed-off-by: Jeremy Cline <jeremycline@microsoft.com>
Not totally sure about this one, I've removed a couple of test
conditions where it seems like an image was expected to be filtered out
but the only thing which has changed since the previous line was
removing the thing that caused it to be filtered in the first place.
Happy to put these back if someone can explain what the intention was.
This loads the credentials from a number of sources (azure-cli login,
environment variables, etc).
For production, we expect the AZURE_CLIENT_ID, AZURE_TENANT_ID, and
AZURE_CLIENT_SECRET or AZURE_CLIENT_CERTIFICATE_PATH variables to be
set.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
The parameter changed from "id" to "storage_account_id" when uploading,
presumably because the id field is used for the resource itself and not
the storage account. This breaking change was recently enforced server
side.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
This is in preparation to add a garbage collection task for our Azure
subscription like the AWS account has. Resources including a "Delete"
tag with a date will be deleted after that date.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
ELN now uses subvariants for all images to match CS and RHEL, which is
necessary to avoid collisions between images.
https://pagure.io/cloud-image-uploader/issue/62
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
Quay says you can add annotations to expire images, but doing this in
the image index doesn't appear to do anything. Maybe the manifest is
where they're supposed to go?
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
This adjusts the tags pushed to quay.io to include nightly tags set to
expire when the image reaches EOL.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
Breaking this into two separate functions and hoisting the registry loop
up makes it easier to adjust what gets pushed to each repository. This
is prep work for pushing nightly build tags to Quay, which supports
annotations for garbage collection.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
GCP really, _really_ wants credentials to do anything. There's not an
obvious easy way to test like AWS has. Skip the tests for normal runs
since most people won't have credentials set up.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
Unlike Fedora composes, Fedora-IoT composes are always numbered
- there's never an IoT compose with "Rawhide" as the version.
Right now for e.g. IoT is doing composes with "43" as the
version.
They want us to update the "rawhide" tag for composes with the
release number currently associated with Rawhide, so this will
make that happen.
Add an IoT compose to test_containers so we can check that this
works (and that IoT composes are otherwise handled correctly).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Azure upload code skips uploading if the EOL date is close or
has passed, so all tests that used stable_nightly_compose.json
were broken recently because the F40 EOL date passed. This updates
the fixture to be a more recent stable nightly.
While fixing this I noticed the EOL synthesis test was broken
since aac47f3 - that removed all the assertions from the test,
it was just assigning values to things. This fixes it to use
correct assertions again, and then fixes problems with the changed
mocks that become apparent when you make the test actually assert
things again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The existing VCR "cassettes" don't work with current fedfind,
but we can't re-record them because the composes in the tests no
longer exist on the server. So change the tests to use current
composes and re-record the cassettes. We also need to adjust
test expectations and re-record cassettes for some other tests
that use the same data. I split off the old rc_compose.json as
rc_compose_40.json for the GCP tests, because I don't have gcloud
API access set up to re-record those cassettes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The ELN WSL image has variant/subvariant "BaseOS" which is what their
container image has, as well. Its "type" is also "docker", so it is
being picked up by the container uploader. Add a hacky skip until
they've adjusted their subvariant.
This should be reverted after a couple days.
Signed-off-by: Jeremy Cline <jeremycline@linux.microsoft.com>
This loop handles multiple repo/images pairs. Just because an
expected arch is missing for *one* repo doesn't mean we should
bail out of possibly publishing manifests for *all subsequent*
repos in the compose. This is currently causing us not to
publish the multi-arch manifest for fedora-bootc because we're
failing the check for fedora-iot, even though fedora-bootc would
pass the check fine.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These are only present in the current manifest by mistake (we
got the IoT and base images mixed up). IoT isn't actually meant
to be built for these arches. Now we've fixed the mixup, though,
sync is failing every day because the current manifest has these
arches in it. Use the mechanism I added in #45 to allow them to
be missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The PR mentioned in the comment was merged months ago, and I
backported it for all stable branches. We shouldn't have this bad
metadata in any current composes any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems families should only have images of a single architecture in
them, rather than being a container for multiple architectures of the
same release. Swap the arch suffix from the image name to the image
family.
See also: https://pagure.io/cloud-sig/issue/438
re-using the request-id from the insert call results in an HTTP 400; we
still want it to depend on the image sha, so just use a different offset
in the checksum.
