Merge branch 'dependabot/go_modules/google.golang.org/protobuf-1.33.0…

…' of github.com:argoproj/argo-rollouts into dependabot/go_modules/google.golang.org/protobuf-1.33.0

Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>

.github/workflows/docker-publish.yml

@@ -67,7 +67,7 @@ jobs:
     with:
       quay_image_name: ${{ needs.set-vars.outputs.controller-meta-tags }}
       # Note: cannot use env variables to set go-version (https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations)
-      go-version: '1.20'
+      go-version: '1.21'
       platforms: ${{ needs.set-vars.outputs.platforms }}
       push: ${{ github.event_name != 'pull_request' }}
     secrets:
@@ -84,7 +84,7 @@ jobs:
     with:
       quay_image_name: ${{ needs.set-vars.outputs.plugin-meta-tags }}
       # Note: cannot use env variables to set go-version (https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations)
-      go-version: '1.20'
+      go-version: '1.21'
       platforms: ${{ needs.set-vars.outputs.platforms }}
       push: ${{ github.event_name != 'pull_request' }}
       target: kubectl-argo-rollouts

.github/workflows/e2e.yaml

@@ -48,7 +48,7 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v5.0.0
         with:
-          go-version: '1.20'
+          go-version: '1.21'
       - uses: actions/checkout@v4
       - name: Setup k3s
         env:

.github/workflows/gh-pages.yaml

@@ -26,7 +26,7 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v5.0.0
         with:
-          go-version: '1.20'
+          go-version: '1.21'
       - name: build
         run: |
           pip install mkdocs mkdocs_material

.github/workflows/go.yml

@@ -9,7 +9,7 @@ on:
       - "master"
 env:
   # Golang version to use across CI steps
-  GOLANG_VERSION: '1.20'
+  GOLANG_VERSION: '1.21'
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
@@ -44,7 +44,7 @@ jobs:
       - name: Run golangci-lint
         uses: golangci/golangci-lint-action@v4
         with:
-          version: v1.53.3
+          version: v1.57.2
           args: --timeout 6m
   build:
     name: Build
@@ -90,7 +90,7 @@ jobs:
           path: coverage.out
 
       - name: Upload code coverage information to codecov.io
-        uses: codecov/codecov-action@v4.1.0
+        uses: codecov/codecov-action@v4.1.1
         with:
           file: coverage.out
 

.github/workflows/release.yaml

@@ -7,7 +7,7 @@ on:
 permissions: {}
 
 env:
-  GOLANG_VERSION: '1.20' # Note: go-version must also be set in job controller-image.with.go-version & plugin-image.with.go-version.
+  GOLANG_VERSION: '1.21' # Note: go-version must also be set in job controller-image.with.go-version & plugin-image.with.go-version.
 
 jobs:
   controller-image:
@@ -19,7 +19,7 @@ jobs:
     with:
       quay_image_name: quay.io/argoproj/argo-rollouts:${{ github.ref_name }}
       # Note: cannot use env variables to set go-version (https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations)
-      go-version: '1.20'
+      go-version: '1.21'
       platforms: linux/amd64,linux/arm64
       push: true
     secrets:
@@ -35,7 +35,7 @@ jobs:
     with:
       quay_image_name: quay.io/argoproj/kubectl-argo-rollouts:${{ github.ref_name }}
       # Note: cannot use env variables to set go-version (https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations)
-      go-version: '1.20'
+      go-version: '1.21'
       platforms: linux/amd64,linux/arm64
       push: true
       target: kubectl-argo-rollouts
@@ -51,7 +51,7 @@ jobs:
         id-token: write # for creating OIDC tokens for signing.
         packages: write # for uploading attestations. (https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#known-issues)
       # Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
-      uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
+      uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.10.0
       with:
         image: quay.io/argoproj/argo-rollouts
         digest: ${{ needs.controller-image.outputs.image-digest }}
@@ -67,7 +67,7 @@ jobs:
         id-token: write # for creating OIDC tokens for signing.
         packages: write # for uploading attestations. (https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#known-issues)
       # Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
-      uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
+      uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.10.0
       with:
         image: quay.io/argoproj/kubectl-argo-rollouts
         digest: ${{ needs.plugin-image.outputs.image-digest }}
@@ -141,7 +141,7 @@ jobs:
       id-token: write # Needed for provenance signing and ID
       contents: write #  Needed for release uploads
     # Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
-    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
+    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.10.0
     with:
       base64-subjects: "${{ needs.release-artifacts.outputs.hashes }}"
       provenance-name: "argo-rollouts.intoto.jsonl"

Dockerfile

@@ -3,7 +3,7 @@
 # Initial stage which pulls prepares build dependencies and CLI tooling we need for our final image
 # Also used as the image in CI jobs so needs all dependencies
 ####################################################################################################
-FROM --platform=$BUILDPLATFORM golang:1.20 as builder
+FROM --platform=$BUILDPLATFORM golang:1.21 as builder
 
 RUN apt-get update && apt-get install -y \
     wget \
@@ -12,7 +12,7 @@ RUN apt-get update && apt-get install -y \
     rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
 
 # Install golangci-lint
-RUN curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.53.3 && \
+RUN curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.57.2 && \
     golangci-lint linters
 
 COPY .golangci.yml ${GOPATH}/src/dummy/.golangci.yml
@@ -40,7 +40,7 @@ RUN NODE_ENV='production' yarn build
 ####################################################################################################
 # Rollout Controller Build stage which performs the actual build of argo-rollouts binaries
 ####################################################################################################
-FROM --platform=$BUILDPLATFORM golang:1.20 as argo-rollouts-build
+FROM --platform=$BUILDPLATFORM golang:1.21 as argo-rollouts-build
 
 WORKDIR /go/src/github.com/argoproj/argo-rollouts
 

USERS.md

@@ -16,6 +16,7 @@ Organizations below are **officially** using Argo Rollouts. Please send a PR wit
 1. [DaoCloud](https://daocloud.io)
 1. [Databricks](https://github.com/databricks)
 1. [Devtron Labs](https://github.com/devtron-labs/devtron)
+1. [Factorial](https://factorialhr.com)
 1. [Farfetch](https://www.farfetch.com/)
 1. [Flipkart](https://flipkart.com)
 1. [GetYourGuide](https://www.getyourguide.com)
@@ -50,3 +51,4 @@ 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)
+2. [Groww](https://groww.in/)

analysis/controller_test.go

@@ -5,6 +5,7 @@ import (
 	"encoding/json"
 	"fmt"
 	"reflect"
+	"sync"
 	"testing"
 	"time"
 
@@ -50,9 +51,13 @@ type fixture struct {
 	// Actions expected to happen on the client.
 	actions []core.Action
 	// Objects from here preloaded into NewSimpleFake.
-	objects         []runtime.Object
-	enqueuedObjects map[string]int
-	unfreezeTime    func() error
+	objects []runtime.Object
+
+	// Acquire 'enqueuedObjectMutex' before accessing enqueuedObjects
+	enqueuedObjects     map[string]int
+	enqueuedObjectMutex sync.Mutex
+
+	unfreezeTime func() error
 	// fake provider
 	provider *mocks.Provider
 
@@ -66,11 +71,11 @@ func newFixture(t *testing.T) *fixture {
 	f.objects = []runtime.Object{}
 	f.enqueuedObjects = make(map[string]int)
 	f.now = time.Now()
-	timeutil.Now = func() time.Time {
+	timeutil.SetNowTimeFunc(func() time.Time {
 		return f.now
-	}
+	})
 	f.unfreezeTime = func() error {
-		timeutil.Now = time.Now
+		timeutil.SetNowTimeFunc(time.Now)
 		return nil
 	}
 	return f
@@ -122,6 +127,10 @@ func (f *fixture) newController(resync resyncFunc) (*Controller, informers.Share
 		if key, err = cache.MetaNamespaceKeyFunc(obj); err != nil {
 			panic(err)
 		}
+
+		f.enqueuedObjectMutex.Lock()
+		defer f.enqueuedObjectMutex.Unlock()
+
 		count, ok := f.enqueuedObjects[key]
 		if !ok {
 			count = 0

controller/metrics/prommetrics.go

@@ -135,7 +135,7 @@ var (
 	MetricAnalysisTemplateInfo = prometheus.NewDesc(
 		"analysis_template_info",
 		"Information about analysis templates.",
-		append(namespaceNameLabels),
+		namespaceNameLabels,
 		nil,
 	)
 

docs/best-practices.md

@@ -1,6 +1,71 @@
 # Best Practices
 
-This document describes some best practices, tips and tricks when using Argo Rollouts.
+This document describes some best practices, tips and tricks when using Argo Rollouts. Be sure to read the [FAQ page](../FAQ) as well.
+
+
+## Check application compatibility
+
+Argo Rollouts is a great solution for applications that your team is deploying in a continuous manner (and you have access to the source code). Before using Argo Rollouts you need to contact the developers of the application and verify that you can indeed run multiple versions of the same application at the same time. 
+
+Not all applications can work with Argo Rollouts. Applications that use shared resources (e.g. writing to a shared file) will have issues, and "worker" type applications (that load data from queues) will rarely work ok without source code modifications.
+
+Note that using Argo Rollouts for "infrastructure" applications such as cert-manager, nginx, coredns, sealed-secrets etc is **NOT** recommended.
+
+## Understand the scope of Argo Rollouts
+
+Currently Argo Rollouts works with a single Kubernetes deployment/application and within a single cluster only. You also need to have the controller deployed on *every* cluster where a Rollout is running if have more than one clusters using Rollout workloads.
+
+If you want to look at multiple-services on multiple clusters
+see discussion at issues [2737](https://github.com/argoproj/argo-rollouts/issues/2737), [451](https://github.com/argoproj/argo-rollouts/issues/451) and [2088](https://github.com/argoproj/argo-rollouts/issues/2088).
+
+
+Note also that Argo Rollouts is a self-contained solution. It doesn't need Argo CD or any other Argo project to work.
+
+## Understand your use case
+
+Argo Rollouts is perfect for all progressive delivery scenarios as explained in [the concepts page](../concepts).
+
+You should *NOT* use Argo Rollouts for preview/ephemeral environments. For that use case check the [Argo CD Pull Request generator](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Pull-Request/).
+
+The recommended way to use Argo Rollouts is for brief deployments that take 15-20 minutes or maximum 1-2 hours. If you want to run new versions for days or weeks before deciding to promote, then Argo Rollouts is probably not the best solution for you.
+
+Also, if you want to run a wave of multiple versions at the same time (i.e. have 1.1 and 1.2 and 1.3 running at the same time), know that Argo Rollouts was not designed for this scenario.
+
+A version that has just been promoted is assumed to be ready for production and has already passed all your tests (either manual or automated).
+
+## Prepare your metrics
+
+The end-goal for using Argo Rollouts is to have **fully automated** deployments that also include rollbacks when needed.
+
+While Argo Rollouts supports manual promotions and other manual pauses, these are best used for experimentation and test reasons.
+
+Ideally you should have proper metrics that tell you in 5-15 minutes if a deployment is successful or not. If you don't have those metrics, then you will miss a lot of value from Argo Rollouts.
+
+Get your [metrics](../features/analysis) in place first and test them with dry-runs before applying them to production deployments.
+
+
+## There is no "Argo Rollouts API"
+
+A lot of people want to find an official API for managing Rollouts. There isn't any separate Argo Rollouts API. You can always use the Kubernetes API and patching of resources if you want to control a rollout.
+
+But as explained in the previous point the end goal should be fully automated deployments without you having to tell Argo Rollouts to promote or abort.
+
+## Integrating with other systems and processes
+
+There are two main ways to integrate other systems with Argo Rollouts.
+
+The easiest way is to use [Notifications](../features/notifications). This means that when a rollout is finished/aborted you send a notification to another system that does other tasks that you want to happen.
+
+Alternatively you can control Rollouts with the CLI or by patching manually the Kubernetes resources.
+
+
+## Use the Kubernetes Downward API
+
+If you want your applications to know if they are part of a canary or not, you can use [Ephemeral labels](../features/ephemeral-metadata) along with the [Kubernetes downward api](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/).
+
+This means that your application will read from files its configuration in a dynamic manner and adapt according to the situation.
+
+
 
 ## Ingress desired/stable host routes
 
@@ -67,8 +132,10 @@ additional load balancers.
 ## Reducing operator memory usage
 
 On clusters with thousands of rollouts memory usage for the argo-rollouts
-operator can be reduced significantly by changing RevisionHistoryLimit from the
-default of 10 to a lower number. One user of Argo Rollouts saw a 27% reduction
+controller can be reduced significantly by changing the `RevisionHistoryLimit` property from the
+default of 10 to a lower number. 
+
+One user of Argo Rollouts saw a 27% reduction
 in memory usage for a cluster with 1290 rollouts by changing
-RevisionHistoryLimit from 10 to 0.
+`RevisionHistoryLimit` from 10 to 0.