Skip to content

Tag all component images with the release tag matching the gitpod-installer image's tag #12812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #13359
mrzarquon opened this issue Sep 9, 2022 · 3 comments
Labels
meta: stale This issue/PR is stale and will be closed soon self-hosted

Comments

@mrzarquon
Copy link
Contributor

mrzarquon commented Sep 9, 2022

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.

Front logo Front conversations

@mrzarquon
Copy link
Contributor Author

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)

@mrzarquon
Copy link
Contributor Author

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.

@stale
Copy link

stale bot commented Dec 16, 2022

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.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Dec 16, 2022
@stale stale bot closed this as completed Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta: stale This issue/PR is stale and will be closed soon self-hosted
Projects
No open projects
Development

No branches or pull requests

1 participant