Currently, Artifactory runs el7 and is managed by Puppet. This brings in extra work if we want to change something.
Let's build a new artifactory instance using Ansible and migrate workloads to it.
looking at ovirt-engine sources, the only endpoint used on artifactory by builds is http://artifactory.ovirt.org/artifactory/ovirt-mirror
We need to create a simple Ansible playbook to install artifactory from RPM (jfrog.com/open-source) and set up the maven mirror at the above path.
Once that is done we can change the FQDN and move CI traffic to the new instance.
Other checks include verifying current settings and logs to see if any other endpoints are in use.
Here’s the current Puppet code that is managing the configuration of the existing instance:
This may be a good time to switch from Artifactory (Proprietary) to Nexus (Open Source).
This may also be a good time to go from a VM to a container in OpenShift. The last time I checked, the Nexus project were providing a ready-to-go container image.
Good point! We are actually providing nexus hosted on OpenShift already, however since it already has a DB it is not as easy to set up automatically as Artifactory. Let’s review the settings of both and get a maven cache working on the Nexus, then talk to the team to get the hardcoded cache overwritten or even better - make CI somehow provide the cache URL during the run instead of having to hard-code it in the sources.
To make CI provide the Maven repo URL:
Define a Jenkins global property with the URL (From the "Manage Jenkins"->"Configure System" screen under "Global properties")
Add a [*.environment.yaml|https://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standards/index.html#environment-dependencies] files to the engine`s automation configuration to expose the variable to the engine`s build scripts by using the valueFrom provider.
Change the engine build code to use the provided value
Since we have a CI system, and most of the work would be done via sending patches to the engine repository, you would get automated verification for your work as you send the patches.
Note: You should ensure the build scripts do not crash if run in an environment that does not have the variable defined. This is done by:
Making sure the build scripts can gracefully avoid using a cache server if the variable is not defined
Marking the variable as optional in the *.environment.yaml files so that running mock-runner locally does not crash
Once you do this, it becomes possible to:
Arbitrarily switch everyone to use a certain cache server in CI by changing a single configuration value in Jenkins
Have different Jenkins servers use different cache server
Test a new cache server by simply sending a temporary patch to the engine repo that modifies the *.environment.yaml files to point to a particular server by using a value field instead of a valueFrom field (Note that this approach is also possible now by changing the hard-coded values in the code).