Following on from #12, I think we should consider creating a dedicated namespace for candidate images to supersede zmkfirmwaredependabot.
Naming suggestions:
zmkfirmware-candidateszmkfirmware-stagingzmkfirmware-testing
The idea being that every candidate image (those tagged only with their associated GitHub SHA) - including dependabot - are pushed to this namespace, and only released images are pushed to the zmkfirmware namespace.
Potential benefits:
- less junk in the
zmkfirmware namespace
- easier discovery and navigation of released images
- reduces chance of users downloading experimental or untested candidates
- easier maintainence (cleaning out redundant images)
- possibly more secure?
Depending on the approach, it might require two sets of credentials to be provided as secrets - one for each namespace.
Care must also be taken around the caching so as to not inadvertantly break the inherent nuances of the design.
Following on from #12, I think we should consider creating a dedicated namespace for candidate images to supersede
zmkfirmwaredependabot.Naming suggestions:
zmkfirmware-candidateszmkfirmware-stagingzmkfirmware-testingThe idea being that every candidate image (those tagged only with their associated GitHub SHA) - including dependabot - are pushed to this namespace, and only released images are pushed to the
zmkfirmwarenamespace.Potential benefits:
zmkfirmwarenamespaceDepending on the approach, it might require two sets of credentials to be provided as secrets - one for each namespace.
Care must also be taken around the caching so as to not inadvertantly break the inherent nuances of the design.