Merge branch 'master' of github.com:argoproj/argo-rollouts into analy…

…sisRun-notifications

.github/workflows/go.yml

@@ -90,7 +90,7 @@ jobs:
           path: coverage.out
 
       - name: Upload code coverage information to codecov.io
-        uses: codecov/codecov-action@v4.0.1
+        uses: codecov/codecov-action@v4.1.0
         with:
           file: coverage.out
 

.github/workflows/image-reuse.yaml

@@ -79,7 +79,7 @@ jobs:
           cosign-release: 'v2.2.0'
 
       - uses: docker/setup-qemu-action@68827325e0b33c7199eb31dd4e31fbe9023e06e3 # v3.0.0
-      - uses: docker/setup-buildx-action@f95db51fddba0c2d1ec667646a06c2ce06100226 # v3.0.0
+      - uses: docker/setup-buildx-action@0d103c3126aa41d772a8362f6aa67afac040f80c # v3.1.0
 
       - name: Setup tags for container image as a CSV type
         run: |
@@ -130,7 +130,7 @@ jobs:
 
       - name: Build and push container image
         id: image
-        uses: docker/build-push-action@4a13e500e55cf31b7a5d59a38ab2040ab0f42f56 #v5.1.0
+        uses: docker/build-push-action@af5a7ed5ba88268d5278f7203fb52cd833f66d6e #v5.2.0
         with:
           context: .
           platforms: ${{ inputs.platforms }}

.github/workflows/release.yaml

@@ -99,7 +99,7 @@ jobs:
         uses: docker/setup-qemu-action@68827325e0b33c7199eb31dd4e31fbe9023e06e3 # v3.0.0
 
       - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@f95db51fddba0c2d1ec667646a06c2ce06100226 # v3.0.0
+        uses: docker/setup-buildx-action@0d103c3126aa41d772a8362f6aa67afac040f80c # v3.1.0
 
       - name: Generate release artifacts
         run: |
@@ -108,7 +108,7 @@ jobs:
           make manifests IMAGE_TAG=${{ github.ref_name }}
 
       - name: Draft release
-        uses: softprops/action-gh-release@de2c0eb89ae2a093876385947365aca7b0e5f844 # v0.1.15
+        uses: softprops/action-gh-release@9d7c94cfd0a1f3ed45544c887983e9fa900f0564 # v0.1.15
         with:
           tag_name: ${{ github.event.inputs.tag }}
           draft: true
@@ -214,7 +214,7 @@ jobs:
             /tmp/sbom.tar.gz
 
       - name: Upload SBOM and signature assets
-        uses: softprops/action-gh-release@de2c0eb89ae2a093876385947365aca7b0e5f844 # v0.1.15
+        uses: softprops/action-gh-release@9d7c94cfd0a1f3ed45544c887983e9fa900f0564 # v0.1.15
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

USERS.md

@@ -1,6 +1,7 @@
 ## Who uses Argo Rollouts?
 Organizations below are **officially** using Argo Rollouts. Please send a PR with your organization name if you are using Argo Rollouts.
 
+1. [Ada](https://www.ada.cx)
 1. [ADP](https://www.adp.com)
 1. [Akuity](https://akuity.io/)
 1. [Alibaba Group](https://www.alibabagroup.com/)
@@ -19,6 +20,7 @@ Organizations below are **officially** using Argo Rollouts. Please send a PR wit
 1. [Flipkart](https://flipkart.com)
 1. [GetYourGuide](https://www.getyourguide.com)
 1. [Gllue](https://gllue.com)
+1. [HashiCorp](https://www.hashicorp.com/)
 1. [Ibotta](https://home.ibotta.com/)
 1. [Intuit](https://www.intuit.com/)
 1. [New Relic](https://newrelic.com/)
@@ -48,4 +50,3 @@ Organizations below are **officially** using Argo Rollouts. Please send a PR wit
 1. [WeLab Bank](https://www.welab.bank/)
 1. [Yotpo](https://www.yotpo.com/)
 1. [VGS](https://www.vgs.io)
-1. [HashiCorp](https://www.hashicorp.com/)

analysis/controller.go

@@ -6,6 +6,7 @@ import (
 	"time"
 
 	"github.com/argoproj/argo-rollouts/metric"
+	jobProvider "github.com/argoproj/argo-rollouts/metricproviders/job"
 
 	unstructuredutil "github.com/argoproj/argo-rollouts/utils/unstructured"
 
@@ -106,13 +107,13 @@ func NewController(cfg ControllerConfig) *Controller {
 
 	cfg.JobInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
 		AddFunc: func(obj any) {
-			controller.enqueueIfCompleted(obj)
+			controller.enqueueJobIfCompleted(obj)
 		},
 		UpdateFunc: func(oldObj, newObj any) {
-			controller.enqueueIfCompleted(newObj)
+			controller.enqueueJobIfCompleted(newObj)
 		},
 		DeleteFunc: func(obj any) {
-			controller.enqueueIfCompleted(obj)
+			controller.enqueueJobIfCompleted(obj)
 		},
 	})
 
@@ -186,15 +187,29 @@ func (c *Controller) syncHandler(ctx context.Context, key string) error {
 	return c.persistAnalysisRunStatus(run, newRun.Status)
 }
 
-func (c *Controller) enqueueIfCompleted(obj any) {
+func (c *Controller) jobParentNamespace(obj any) string {
+	job, ok := obj.(*batchv1.Job)
+	if !ok {
+		return ""
+	}
+	ns := job.GetNamespace()
+	if job.Annotations != nil {
+		if job.Annotations[jobProvider.AnalysisRunNamespaceAnnotationKey] != "" {
+			ns = job.Annotations[jobProvider.AnalysisRunNamespaceAnnotationKey]
+		}
+	}
+	return ns
+}
+
+func (c *Controller) enqueueJobIfCompleted(obj any) {
 	job, ok := obj.(*batchv1.Job)
 	if !ok {
 		return
 	}
 	for _, condition := range job.Status.Conditions {
 		switch condition.Type {
 		case batchv1.JobFailed, batchv1.JobComplete:
-			controllerutil.EnqueueParentObject(job, register.AnalysisRunKind, c.enqueueAnalysis)
+			controllerutil.EnqueueParentObject(job, register.AnalysisRunKind, c.enqueueAnalysis, c.jobParentNamespace)
 			return
 		}
 	}

cmd/rollouts-controller/main.go

@@ -6,6 +6,7 @@ import (
 	"strings"
 	"time"
 
+	"github.com/argoproj/argo-rollouts/metricproviders"
 	"github.com/argoproj/argo-rollouts/utils/record"
 	"github.com/argoproj/pkg/kubeclientmetrics"
 	smiclientset "github.com/servicemeshinterface/smi-sdk-go/pkg/gen/client/split/clientset/versioned"
@@ -131,6 +132,7 @@ func newCommand() *cobra.Command {
 			discoveryClient, err := discovery.NewDiscoveryClientForConfig(config)
 			checkError(err)
 			smiClient, err := smiclientset.NewForConfig(config)
+			checkError(err)
 			resyncDuration := time.Duration(rolloutResyncPeriod) * time.Second
 			kubeInformerFactory := kubeinformers.NewSharedInformerFactoryWithOptions(
 				kubeClient,
@@ -140,10 +142,17 @@ func newCommand() *cobra.Command {
 			instanceIDTweakListFunc := func(options *metav1.ListOptions) {
 				options.LabelSelector = instanceIDSelector.String()
 			}
+			jobKubeClient, err := metricproviders.GetAnalysisJobClientset(kubeClient)
+			checkError(err)
+			jobNs := metricproviders.GetAnalysisJobNamespace()
+			if jobNs == "" {
+				// if not set explicitly use the configured ns
+				jobNs = namespace
+			}
 			jobInformerFactory := kubeinformers.NewSharedInformerFactoryWithOptions(
-				kubeClient,
+				jobKubeClient,
 				resyncDuration,
-				kubeinformers.WithNamespace(namespace),
+				kubeinformers.WithNamespace(jobNs),
 				kubeinformers.WithTweakListOptions(func(options *metav1.ListOptions) {
 					options.LabelSelector = jobprovider.AnalysisRunUIDLabelKey
 				}))

docs/CONTRIBUTING.md

@@ -247,6 +247,23 @@ pushed into the other kubernetes repositories yet. In order to import the kubern
 associated repos have to pinned to the correct version specified by the kubernetes/kubernetes release. The
 `./hack/update-k8s-dependencies.sh` updates all the dependencies to the those correct versions.
 
+## Upgrading Notifications Engine
+Argo Rollouts has a dependency on the [argoproj/notifications-engines](https://github.com/argoproj/notifications-engine) repo 
+for the notifications functionality and related documentation. 
+
+This is updated by upgrading the Go library in `go.mod` by running the commands:
+
+```shell
+go get github.com/argoproj/notifications-engine@LATEST_COMMIT_HASH
+go mod tidy
+```
+
+Next the latest notifications documentation can be imported by running:
+
+```shell
+make docs
+```
+
 ## Documentation Changes
 
 Modify contents in `docs/` directory.

docs/features/canary.md

@@ -1,13 +1,13 @@
 # Canary Deployment Strategy
-A canary rollout is a deployment strategy where the operator releases a new version of their application to a small percentage of the production traffic. 
+A canary rollout is a deployment strategy where the operator releases a new version of their application to a small percentage of the production traffic.
 
 ## Overview
 Since there is no agreed upon standard for a canary deployment, the rollouts controller allows users to outline how they want to run their canary deployment. Users can define a list of steps the controller uses to manipulate the ReplicaSets when there is a change to the `.spec.template`. Each step will be evaluated before the new ReplicaSet is promoted to the stable version, and the old version is completely scaled down.
 
 Each step can have one of two fields. The `setWeight` field dictates the percentage of traffic that should be sent to the canary, and the `pause` struct instructs the rollout to pause.  When the controller reaches a `pause` step for a rollout, it will add a `PauseCondition` struct to the `.status.PauseConditions` field. If the `duration` field within the `pause` struct is set, the rollout will not progress to the next step until it has waited for the value of the `duration` field. Otherwise, the rollout will wait indefinitely until that Pause condition is removed. By using the `setWeight` and the `pause` fields, a user can declaratively describe how they want to progress to the new version. Below is an example of a canary strategy.
 
 !!! important
-    If the canary Rollout does not use [traffic management](traffic-management/index.md), the Rollout makes a best effort attempt to achieve the percentage listed in the last `setWeight` step between the new and old version. For example, if a Rollout has 10 Replicas and 10% for the first `setWeight` step, the controller will scale the new desired ReplicaSet to 1 replicas and the old stable ReplicaSet to 9. In the case where the setWeight is 15%, the Rollout attempts to get there by rounding up the calculation (i.e. the new ReplicaSet has 2 pods since 15% of 10 rounds up to 2 and the old ReplicaSet has 9 pods since 85% of 10 rounds up to 9). If a user wants to have more fine-grained control of the percentages without a large number of Replicas, that user should use the  [traffic management](#trafficrouting) functionality.
+    If the canary Rollout does not use [traffic management](traffic-management/index.md), the Rollout makes a best effort attempt to achieve the percentage listed in the last `setWeight` step between the new and old version. For example, if a Rollout has 10 Replicas and 10% for the first `setWeight` step, the controller will scale the new desired ReplicaSet to 1 replicas and the old stable ReplicaSet to 9. In the case where the setWeight is 41%, the Rollout attempts to get there by finding the whole number with the smallest delta, rounding up the calculation if the deltas are equals (i.e. the new ReplicaSet has 4 pods since 41% of 10 is closer to 4/10 than 5/10, and the old ReplicaSet has 6 pods). If a user wants to have more fine-grained control of the percentages without a large number of Replicas, that user should use the  [traffic management](#trafficrouting) functionality.
 
 ## Example
 ```yaml
@@ -59,7 +59,7 @@ spec:
         - pause: {}                # pause indefinitely
 ```
 
-If no `duration` is specified for a pause step, the rollout will be paused indefinitely. To unpause, use the [argo kubectl plugin](kubectl-plugin.md) `promote` command. 
+If no `duration` is specified for a pause step, the rollout will be paused indefinitely. To unpause, use the [argo kubectl plugin](kubectl-plugin.md) `promote` command.
 
 ```shell
 # promote to the next step

docs/features/specification.md

@@ -386,6 +386,9 @@ spec:
       # will achieve traffic split via a weighted replica counts between
       # the canary and stable ReplicaSet.
       trafficRouting:
+        # Supports nginx and plugins only: This lets you control the denominator or total weight of traffic.
+        # The total weight of traffic. If unspecified, it defaults to 100
+        maxTrafficWeight: 1000
         # This is a list of routes that Argo Rollouts has the rights to manage it is currently only required for
         # setMirrorRoute and setHeaderRoute. The order of managedRoutes array also sets the precedence of the route
         # in the traffic router. Argo Rollouts will place these routes in the order specified above any routes already

docs/features/traffic-management/plugins.md

@@ -73,6 +73,9 @@ responsibility of the Argo Rollouts administrator to define the plugin installat
 * This is just a sample plugin that can be used as a starting point for creating your own plugin.
   It is not meant to be used in production. It is based on the built-in prometheus provider.
 
+#### [Consul](https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-consul)
+* This is a plugin that allows argo-rollouts to work with Consul's service mesh for traffic shaping patterns.
+
 #### [Contour](https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-contour)
 * This is a plugin that allows argo-rollouts to work with contour's resource: HTTPProxy. It enables traffic shaping patterns such as canary releases and more.
 

docs/generated/notification-services/alertmanager.md

@@ -43,7 +43,7 @@ You should turn off "send_resolved" or you will receive unnecessary recovery not
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.alertmanager: |
     targets:
@@ -58,7 +58,7 @@ If your alertmanager has changed the default api, you can customize "apiPath".
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.alertmanager: |
     targets:
@@ -70,7 +70,7 @@ data:
 
 ### Send high availability alertmanager with auth
 
-Store auth token in `argocd-notifications-secret` Secret and use configure in `argocd-notifications-cm` ConfigMap.
+Store auth token in `argo-rollouts-notification-secret` Secret and use configure in `argo-rollouts-notification-configmap` ConfigMap.
 
 ```yaml
 apiVersion: v1
@@ -89,7 +89,7 @@ stringData:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.alertmanager: |
     targets:
@@ -110,7 +110,7 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.alertmanager: |
     targets:

docs/generated/notification-services/awssqs.md

@@ -1,8 +1,8 @@
-# AWS SQS 
+# AWS SQS
 
 ## Parameters
 
-This notification service is capable of sending simple messages to AWS SQS queue. 
+This notification service is capable of sending simple messages to AWS SQS queue.
 
 * `queue` - name of the queue you are intending to send messages to. Can be overridden with target destination annotation.
 * `region` - region of the sqs queue can be provided via env variable AWS_DEFAULT_REGION
@@ -30,7 +30,7 @@ metadata:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.awssqs: |
     region: "us-east-2"
@@ -63,7 +63,7 @@ stringData:
 
 ### Minimal configuration using AWS Env variables
 
-Ensure following list of environment variables are injected via OIDC, or other method. And assuming SQS is local to the account.
+Ensure the following list of environment variables are injected via OIDC, or another method. And assuming SQS is local to the account.
 You may skip usage of secret for sensitive data and omit other parameters. (Setting parameters via ConfigMap takes precedent.)
 
 Variables:
@@ -89,7 +89,7 @@ metadata:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.awssqs: |
     queue: "myqueue"
@@ -104,3 +104,16 @@ data:
     - oncePer: obj.metadata.annotations["generation"]
 
 ```
+
+## FIFO SQS Queues
+
+FIFO queues require a [MessageGroupId](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#SQS-SendMessage-request-MessageGroupId) to be sent along with every message, every message with a matching MessageGroupId will be processed one by one in order.
+
+To send to a FIFO SQS Queue you must include a `messageGroupId` in the template such as in the example below:
+
+```yaml
+template.deployment-ready: |
+  message: |
+    Deployment {{.obj.metadata.name}} is ready!
+  messageGroupId: {{.obj.metadata.name}}-deployment
+```

docs/generated/notification-services/email.md

@@ -20,7 +20,7 @@ The following snippet contains sample Gmail service configuration:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.email.gmail: |
     username: $email-username
@@ -36,7 +36,7 @@ Without authentication:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.email.example: |
     host: smtp.example.com
@@ -52,7 +52,7 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   template.app-sync-succeeded: |
     email:

docs/generated/notification-services/github.md

@@ -17,14 +17,14 @@ The GitHub notification service changes commit status using [GitHub Apps](https:
 3. Generate a private key, and download it automatically
 ![3](https://user-images.githubusercontent.com/18019529/108397926-d4a36300-725b-11eb-83fe-74795c8c3e03.png)
 4. Install app to account
-5. Store privateKey in `argocd-notifications-secret` Secret and configure GitHub integration
-in `argocd-notifications-cm` ConfigMap
+5. Store privateKey in `argo-rollouts-notification-secret` Secret and configure GitHub integration
+in `argo-rollouts-notification-configmap` ConfigMap
 
 ```yaml
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: <config-map-name>
+  name: argo-rollouts-notification-configmap
 data:
   service.github: |
     appID: <app-id>
@@ -76,6 +76,7 @@ template.app-deployed: |
       logURL: "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true"
       requiredContexts: []
       autoMerge: true
+      transientEnvironment: false
     pullRequestComment:
       content: |
         Application {{.app.metadata.name}} is now running new version of deployments manifests.