Update kargo Docker tag to v1.6.0 #25
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
Reviewer's GuideThis PR implements a minor version bump of the kargo Helm chart from v1.5.3 to v1.6.0 by updating the chart’s dependency version and regenerating the lockfile. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.5.3->1.6.0Release Notes
akuity/kargo (kargo)
v1.6.0Compare Source
The Kargo team is excited to bring you v1.6.0, which delivers several eagerly anticipated features! Let's take a look!
🆕 What's New?
🪝 Webhooks
In Kargo's initial prototype nearly three years ago, we relied exclusively on webhook requests sent by external platforms like GitHub or Docker Hub to inform Kargo of the existence of new artifacts. As anyone who's worked with webhooks before likely knows, webhooks are not an entirely reliable means of notification. If your server is down, a missed notification is missed forever.☹️ It wasn't long before we changed our approach to Warehouses that periodically poll for new artifacts in a process we call "discovery." Although more reliable, discovery can be very inefficient. Even with aggressive caching on the Kargo side, architectural idiosyncrasies of OCI registries (used for container images or Helm charts) can make discovery a very "chatty" process. ☎️ Given that Kargo can execute a finite number of these processes concurrently and given that many OCI registries aggressively enforcement rate limits, system-wide performance of Warehouses can be quite... slow. 🐌 Although Warehouses poll for new artifacts every five minutes (by default) under nominal conditions, poor Warehouse performance could result in much, much longer intervals before Kargo effectively notices new artifacts.
One can easily see why it would be desirable to avoid executing discovery processes frequently if occurrences of those processes actually finding new artifacts is, comparatively, infrequent. So, counter-intuitively, configuring Warehouses to execute their discovery processes less frequently could improve system-wide performance -- at the expense of individual Warehouses still not noticing new artifacts any faster than before.
The ideal solution to this conundrum is for scheduled discovery to occur at much greater intervals (i.e. much less frequently), but for Warehouses to be notified when an ad-hoc discovery process would be guaranteed to find new artifacts (which we do not wish to depend upon exclusively since such notifications are less reliable). Thus, Kargo v1.6.0's "anchor feature" is the introduction of robust webhook support. ⚓️
Webhook receivers for popular Git hosting platforms and OCI registries are easily configured at the Project level (using the
ProjectConfigresource introduced in v1.5.0) or at the system level using a brand newClusterConfigresource. A webhook receiver configured at the Project level will prompt Warehouses within the Project to execute discovery of new artifacts only if they are subscribed to the repository from which an inbound webhook request originated. A receiver configured at the system level will do the same for Warehouses across all Projects. These receivers make it practical for Project admins and Kargo system admins alike to reduce the frequency of discovery processes that are less likely to find new artifacts and still execute a discovery process promptly when new artifacts are guaranteed to be found.v1.6.0 delivers webhook receivers for the following platforms, with more to come in future releases:
For general information and "how-tos" pertaining to webhook receivers, refer to Kargo's Working with Warehouses documentation. Individual receivers each have their own reference documentation as well.
main), a webhook request notifying Kargo of a push event to that repository will trigger that Warehouse's artifact discovery process even if the push were to some other branch (for example, a feature branch or Stage-specific "rendered" branch). The same applies to container image repositories. If, for instance, a Warehouse subscribes to semantically versioned images in some repository, but is notified that an image tagged non-semantically has been pushed, that Warehouse's discovery process will still execute. Depending on the level of activity in your repositories, you may wish not to use this feature yet. The Kargo team is intent on optimizing our webhook support in the v1.7.0 timeframe so that details of a Warehouse's subscriptions are utilized to filter events and prevent unnecessarily triggering discovery processes.💥 We are just getting started where webhooks are concerned. With the general framework now in place for receiving and acting on notifications from external systems, we intend to speed up other parts of Kargo. For instance, we may begin using notifications of PRs being merged (or closed unmerged) to resume any applicable Promotion currently paused on a
git-wait-for-prstep.🎂 Other Features
With the Kargo team having been so intently focused on webhooks, all the other features are the icing on the proverbial cake. But this frosting is tasty!
Here is a non-exhaustive list of notable features included in this release:
Stages with a single upstream Stage now have an option in the UI to promote whatever Freight is present in the upstream. (Think of this as "pulling" from upstream.)
When promoting Freight to a Stage using the UI, remaining soak time before a given promotion is permitted is now displayed (when applicable).
For Kargo instances authenticating users via Open ID Connect, all claims from a logged-in user's identity token are now visible to that user on the user page. This is expected to be helpful to users and administrators alike when troubleshooting permission problems.
ProjectConfigresources introduced in v1.5.0 can now be created, edited, and deleted via the UI. The newly introducedClusterConfigresources can also be managed through the UI.ConfigMapresources can now be created, edited, and deleted using the UI.Warehouse subscriptions to Git repositories may now utilize expressions to to select or ignore commits on the basis of commit metadata.
Beta: Kubernetes namespaces "adopted" by Kargo Projects can be configured to be retained (instead of deleted), when the Project is deleted.
🚨 Breaking Changes
git-commitpromotion step will now complete with aSkippedstatus instead ofSucceededif it detects there no diffs in the working tree.None
🙏 First Time Contributors
As always, we would love to thank all first-time community contributors for their efforts! This release includes contributions from:
Full Changelog: akuity/kargo@v1.5.3...v1.6.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.