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
I’d like to check if you have a way to achieve the following:
We have a monorepo for and in our system, we already have a method for tracking when a project has changed. We want to find a way to take advantage of this system when integrating with Kargo. Currently, we follow the recommended approach of path filtering commits. This has worked okay, but can both be too aggressive in syncing no-op commits, or missing commits to components shared across teams.We could set up complex include/excludes on the warehouse but it’s tedious and still prone to errors.
In the documentation, a gatekeeper stage is mentioned that would be able to check if this is a valid revisions as left as possible in the pipeline. This would leave many incompatible revisions that still show in the UI which doesn’t entirely meet our usability requirements as we believe it would be confusing for users. If it’s possible to remove these incompatible deployments from history this would be a valid solution.
We considered generating OCI artifacts for a single project, and pointing the warehouse to that. This would inherently filter valid deployments, as our build system would only generate a new OCI artifact when a change is made. From Support OCI manifests #1099 it seems OCI is not supported yet, is there any plans to pick this up?
Our system also stores what has changed with each commit. Another option for us would be if warehouses supported an “advanced filtering” where the warehouse could call a rest API with the metadata of the source. Our server can implement an endpoint that can provide a response that indicates the source should be filtered or not.
If you have any other suggestions that solve our problem, please let us know.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I’d like to check if you have a way to achieve the following:
We have a monorepo for and in our system, we already have a method for tracking when a project has changed. We want to find a way to take advantage of this system when integrating with Kargo. Currently, we follow the recommended approach of path filtering commits. This has worked okay, but can both be too aggressive in syncing no-op commits, or missing commits to components shared across teams.We could set up complex include/excludes on the warehouse but it’s tedious and still prone to errors.
In the documentation, a gatekeeper stage is mentioned that would be able to check if this is a valid revisions as left as possible in the pipeline. This would leave many incompatible revisions that still show in the UI which doesn’t entirely meet our usability requirements as we believe it would be confusing for users. If it’s possible to remove these incompatible deployments from history this would be a valid solution.
We considered generating OCI artifacts for a single project, and pointing the warehouse to that. This would inherently filter valid deployments, as our build system would only generate a new OCI artifact when a change is made. From Support OCI manifests #1099 it seems OCI is not supported yet, is there any plans to pick this up?
Our system also stores what has changed with each commit. Another option for us would be if warehouses supported an “advanced filtering” where the warehouse could call a rest API with the metadata of the source. Our server can implement an endpoint that can provide a response that indicates the source should be filtered or not.
If you have any other suggestions that solve our problem, please let us know.
Thanks for your time!
Beta Was this translation helpful? Give feedback.
All reactions