You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
Currently customers who want to automate mirroring of gitpod releases to an internal registry for installation have to write their own custom tooling, either around download airgapped bundles from replicated or running the gitpod-installer from each release and then parsing the output.
Custom scripts that are brittle and subject to breaking changes in gitpod-installer itself, when it should really be an automated step in the gitpod release process.
Describe the behaviour you'd like
Tools like Nexus and Harbour can be configured to replicate images internally based on tag that match regex patterns, by tagging all component images in a release consistently, customers using these registries can easily automate the internal mirroring of Gitpod releases.
To achieve this, the user would add a list of images to be mirrored to their repository and then add the matching tag regex release-* for each image. Then the mirroring, scanning, and security auditing is now be automated. The only manual steps the user has to do for each release would be to ensure that if we add any new images, those are also added to the mirror job list. This would be complimented by #12813
Even if the images haven't changed, the tag would still need to be updated for every release (tags are cheap) because its a way to mark what releases an artifact is tied to.
This may require we make a more unique tag name (ie, gitpod-release-2022... instead of just release since we have third party components (mysql, registry, fluent) that we will have to tag (and push to our own gcr.io namespace - a benefit because some orgs might also have to perform a separate request for each registry they can mirror from)
This enables an alternative solution to #10359 that would allow us to ship an imageless airgap bundle to customers who have setup their own replication process of our images internally.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Uh oh!
There was an error while loading. Please reload this page.
Is your feature request related to a problem? Please describe
Currently customers who want to automate mirroring of gitpod releases to an internal registry for installation have to write their own custom tooling, either around download airgapped bundles from replicated or running the gitpod-installer from each release and then parsing the output.
Custom scripts that are brittle and subject to breaking changes in gitpod-installer itself, when it should really be an automated step in the gitpod release process.
Describe the behaviour you'd like
Tools like Nexus and Harbour can be configured to replicate images internally based on tag that match regex patterns, by tagging all component images in a release consistently, customers using these registries can easily automate the internal mirroring of Gitpod releases.
To achieve this, the user would add a list of images to be mirrored to their repository and then add the matching tag regex
release-*
for each image. Then the mirroring, scanning, and security auditing is now be automated. The only manual steps the user has to do for each release would be to ensure that if we add any new images, those are also added to the mirror job list. This would be complimented by #12813Even if the images haven't changed, the tag would still need to be updated for every release (tags are cheap) because its a way to mark what releases an artifact is tied to.
The text was updated successfully, but these errors were encountered: