Artifactory management for platform components
What is the recommended approach for managing platform components within our internal JFrog Artifactory? I am currently facing difficulties in defining the appropriate structure. As an example, we are downloading the open-source Apache NiFi image and storing it locally in our Artifactory using the following URL: https://platform-docker-release-local.jfrog.url.net/platform-name/apache/nifi:x.0.0 We release updates on a monthly basis, often upgrading NiFi from version x to version y. We have decided to adopt a versioning strategy based on dates (yy.mm). However, the above URL does not incorporate our internal release version. What would be the best way to include our internal release version while also preserving the original component version? I have considered the following format: https://platform-docker-release-local.jfrog.url.net/platform-name/apache/nifi:x.0.0-v[yy].[mm].0. However, I am uncertain if this is the appropriate approach. Furthermore, we may have custom images based on the open-source images that we create as part of our CI pipeline. For instance, we have a Spark Kubernetes base image built upon spark-3.2.0-bin-hadoop3.2. How should we structure the Artifactory URL to include this information? I have contemplated using the following format: https://platform-docker-release-local.jfrog.url.net/platform-name/bespoke/spark-k8s-base-image_[spark-3.2.0-bin-hadoop3.2]:nv[yy].[mm].[ci]. Please advise.
What is the recommended approach for managing platform components within our internal JFrog Artifactory? I am currently facing difficulties in defining the appropriate structure.
As an example, we are downloading the open-source Apache NiFi image and storing it locally in our Artifactory using the following URL: https://platform-docker-release-local.jfrog.url.net/platform-name/apache/nifi:x.0.0
We release updates on a monthly basis, often upgrading NiFi from version x to version y. We have decided to adopt a versioning strategy based on dates (yy.mm). However, the above URL does not incorporate our internal release version. What would be the best way to include our internal release version while also preserving the original component version? I have considered the following format: https://platform-docker-release-local.jfrog.url.net/platform-name/apache/nifi:x.0.0-v[yy].[mm].0. However, I am uncertain if this is the appropriate approach.
Furthermore, we may have custom images based on the open-source images that we create as part of our CI pipeline. For instance, we have a Spark Kubernetes base image built upon spark-3.2.0-bin-hadoop3.2. How should we structure the Artifactory URL to include this information? I have contemplated using the following format: https://platform-docker-release-local.jfrog.url.net/platform-name/bespoke/spark-k8s-base-image_[spark-3.2.0-bin-hadoop3.2]:nv[yy].[mm].[ci].
Please advise.
