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
When Kargo makes a git commit and/or PR, it would be extremely useful if Kargo included some provenance information/metadata in the commit/PR details about the application contents of what exactly was promoted.
The difference is that Renovate is more geared towards 3rd party dependencies that follow proper semantic versions and release notes that Rennovate can incorporate into the PR.
In the case of this proprosal, it would work with a user's internal services, which may or may not be using semantic versions for their image tags. As long as user could supply "hints" that map a image tag back to the application source code commit, Kargo could formulate GitHub deep links between the current vs. new version.
Today, promoting an image tag is a black box. Often times the image tag has enough information incorporated into the tag (e.g. commit sha), so a user could reverse lookup which commit the image was built from. Kargo could do this work for them, and give reviewers more information about what exactly they are approving as part of the promotion.
Suggested Implementation
When Kargo creates a PR or makes a commit to the gitops repo, it is able to see the image tag before the commit and after the commit. A Kargo user could give "hints" about how these image tags map back to the application repo, in order to create a URL. We already have the gitRepoURL hint, but will need some extraction rule hints.
e.g. If the tag is a semantic version, it could create a link like:
@maksimstankevic, but before you get coding, could you outline how you might approach this. Looks like @jessesuen had some thoughts above, but I haven't put much thought into this yet.
Proposed Feature
When Kargo makes a git commit and/or PR, it would be extremely useful if Kargo included some provenance information/metadata in the commit/PR details about the application contents of what exactly was promoted.
This would be similar to the PRs that https://github.com/renovatebot/renovate creates. e.g.
The difference is that Renovate is more geared towards 3rd party dependencies that follow proper semantic versions and release notes that Rennovate can incorporate into the PR.
In the case of this proprosal, it would work with a user's internal services, which may or may not be using semantic versions for their image tags. As long as user could supply "hints" that map a image tag back to the application source code commit, Kargo could formulate GitHub deep links between the current vs. new version.
We already started down this path of "hints", with the
gitRepoURL
field in Warehouses, but have yet to take advantage of it.https://doc.crds.dev/github.com/akuity/kargo/kargo.akuity.io/Warehouse/v1alpha1@v0.5.1#spec-subscriptions-image-gitRepoURL
Motivation
Today, promoting an image tag is a black box. Often times the image tag has enough information incorporated into the tag (e.g. commit sha), so a user could reverse lookup which commit the image was built from. Kargo could do this work for them, and give reviewers more information about what exactly they are approving as part of the promotion.
Suggested Implementation
When Kargo creates a PR or makes a commit to the gitops repo, it is able to see the image tag before the commit and after the commit. A Kargo user could give "hints" about how these image tags map back to the application repo, in order to create a URL. We already have the gitRepoURL hint, but will need some extraction rule hints.
e.g. If the tag is a semantic version, it could create a link like:
v0.5.0...v0.5.2
If an image incorporates a source code git hash, it could extract the hash to do something similar:
9d358f4...5d53351
Or if a build date is incorporated into the tag, we could generate a link like:
https://github.com/akuity/kargo/commits/v0.5.2?since=2024-04-03&until=2024-04-08
The text was updated successfully, but these errors were encountered: