defenseunicorns
spike: investigate the creation of an automated `registry1` Zarf package publisher
Describe what should be investigated or refactored
Unlike other Defense Unicorns repositories[^1], LeapfrogAI contains over 20 sets of application code, Helm charts, Zarf packaging, and/or UDS bundling sources all within one repository, under one team. With the drive towards different flavors, like -unicorn, -upstream, and -registry1, we will need automated publishing workflows to release all these flavors upon the cutting of a new release in the LeapfrogAI repository.
Unfortunately, LeapfrogAI is subject to various approval processes and delays, particularly with the -registry1 flavor due to IronBank image acceptance. Currently, the -upstream flavor is the only one automatically published to GitHub packages, and there is no automation in place for the -registry1 flavor. To ensure consistent and timely releases of all flavors, we need to implement a more complex workflow, potentially using Renovate or a similar tool, to monitor the state of the images and trigger publishing once approvals are granted.
This workflow should be designed to handle the unique structure of the LeapfrogAI repository, taking into account the different pipelines and approval timelines for each flavor.
[^1]: For example, UDS Core just pulls in upstream charts and/or images, and does not publish application code. Pepr, Lula, and Zarf only require 1 or 2 application and image sources with no internal dependencies, which make them much easier to maintain.
Links to any relevant code
N/A
Additional context
Example issue and MR where IronBank process can delay publishing for days on end: https://repo1.dso.mil/dsop/opensource/defenseunicorns/leapfrogai/api/-/issues/17
The sheer number of LFAI images to run through the process: https://repo1.dso.mil/dsop/opensource/defenseunicorns/leapfrogai
