- Python 99.2%
- Dockerfile 0.8%
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. |
||
|---|---|---|
| fedora-image-tester | ||
| fedora-image-uploader | ||
| fedora-image-uploader-messages | ||
| Containerfile | ||
| Containerfile.fit | ||
| fedora-messaging-fit.toml.example | ||
| fedora-messaging.toml.example | ||
| LICENSE | ||
| README.md | ||
cloud-image-uploader
An AMQP consumer that automatically uploads Cloud and container images to their respective homes.
Configuring
The fedora-messaging service is the container entrypoint and is also used to provide most of the configuration. An example configuration file is included and the full list of options are in fedora-messaging's configuration documentation. The FEDORA_MESSAGING_CONF environment variable should be set to the configuration file's location.
In addition to fedora-messaging, the Azure Ansible collection needs Azure credentials provided. It supports using environment variables, a credentials file at ~/.azure/credentials or the azure-cli credentials. For example, to authenticate via environment variables using an app registration in the Microsoft Entra ID service with a client secret, setting the AZURE_TENANT, AZURE_CLIENT_ID, and AZURE_SECRET along with the AZURE_SUBSCRIPTION_ID will be picked up by the Ansible playbook. The app registration needs to be configured in the given subscription's access control settings.
Container image upload to registries uses the skopeo and buildah commands, so for this to work, the system must be in a state such that these commands have the necessary credentials to upload to the registries configured, non-interactively. If no container registries are configured, container images will not be handled.