We specifically don't add a version tag to the image, because the latest CLI includes all the functionality of the previous builds and removes any functionality no longer supported by the CLI or API.

If someone pulls by version, then that image is not going to be updated. So this creates a situation where users don't keep the image up-to-date and then start opening issues that the CLI doesn't support or even worse, the image has security issues.

Unless you can provide a compelling reason for why versioned images are a good idea in this instance, I'm going to decline this request.

Thank you for the clarification. I understand the concern about users running outdated versions and potential security risks. However, I’d like to provide a few reasons why having a versioned tag for the OCI-CLI Docker images could be beneficial:

• Using latest does not ensure automatic updates – When a container is deployed, it does not automatically update to a newer latest version unless explicitly pulled again. Many users prefer to reference a specific version to ensure stability in their workflows.

• Better traceability – Tagging the image with the corresponding CLI version makes it easier for both users and maintainers to track which version was used in a particular environment. This can be crucial for debugging issues, ensuring reproducibility, and aligning with OCI-CLI documentation. In fact, having a CLI version-tagged container could make debugging even easier, as users could explicitly reference and share the exact version they were running when reporting issues.

• Alignment with best practices – Many official CLI tools and containerized applications provide versioned tags (e.g., AWS CLI, Azure CLI) to allow users to control their environment while still offering a latest tag for those who want the most recent version.

• Avoiding breaking changes in automation – Users integrating OCI-CLI into CI/CD pipelines or scripts might experience unexpected changes when relying on latest. A versioned tag allows for a controlled upgrade process rather than introducing breaking changes unexpectedly.

Thanks again for your time and consideration!

Can you provide more detail on why the date tag is not sufficient for this purpose? Tagging with the version means the CI has to do actual introspection, which is something I'm trying to avoid.

We currently use the date tag and add comments to our deployments to keep track of the CLI version, but it would make much more sense for this to be natively included. Having the version tag directly on the image would remove the need for extra tracking on our end and make it easier to compare against documentation or debug issues. It’s not that the date tag doesn’t work, but adding a version tag would provide better traceability without requiring users to reverse look up a date or access the container just to query the version.

As an alternative to introspecting the image, perhaps you could pull the latest version from the PyPI API and tag the image automatically. Would that be a feasible solution?

It would be even better if the pipeline could query the most recent version of the package and use this value to install the exact version. This will prevent any misalignments between the tag and the CLI present in the Docker image. Additionally, this version could be used to detect if the version already exists, preventing redundant builds.

https://github.com/oracle/docker-images/blob/main/OracleCloudInfrastructure/oci-cli/Dockerfile#L18

ARG OCI_CLI_VERSION 
python3 -m pip install --no-cache-dir oci-cli==${OCI_CLI_VERSION}

It'll be a while before I get a chance to look into this, but we welcome contributions. :) If you're willing and able to modify the GitHub Action that builds the image, I'd be happy to review it.