codefresh-io · ATGardner · Jul 31, 2024 · Jun 18, 2024 · Jun 18, 2024 · Jun 23, 2024
diff --git a/.snyk b/.snyk
@@ -0,0 +1,7 @@
+# Snyk (https://snyk.io) policy file, patches or ignores known vulnerabilities
+version: v1.25.0
+ignore:
+  SNYK-GOLANG-GITHUBCOMJACKCPGXV4-7416900:
+    - '*':
+        reason: "False Positive: vuln is for pgx/v5, not pgx/v4: https://pkg.go.dev/vuln/GO-2024-2567"
+        expires: 2024-09-01T11:11:11.001Z
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,5 +1,33 @@
 # Changelog
 
+## v3.5.8 (2024-06-17)
+
+* [d13891154](https://github.com/argoproj/argo-workflows/commit/d1389115484f52d22d1cdcae29139518cbf2fc03) fix(deps): bump `github.com/Azure/azure-sdk-for-go/sdk/azidentity` from 1.5.1 to 1.6.0 to fix CVE (#13197)
+* [10488d655](https://github.com/argoproj/argo-workflows/commit/10488d655a78c28bb6e3e6bca490a5496addd605) fix: don't necessarily include all artifacts from templates in node outputs (#13066)
+* [c2204ae03](https://github.com/argoproj/argo-workflows/commit/c2204ae03de97acf1c589c898180bdb9942f1524) fix(server): don't use cluster scope list + watch in namespaced mode. Fixes #13177 (#13189)
+* [9481bb04c](https://github.com/argoproj/argo-workflows/commit/9481bb04c3e48a85da5ba05ef47c2f0a2ba500f4) fix(server): mutex calls to sqlitex (#13166)
+* [ee150afdf](https://github.com/argoproj/argo-workflows/commit/ee150afdf3561f8250c5212e1b6a38628a847b39) fix: only evaluate retry expression for fail/error node. Fixes #13058 (#13165)
+* [028f9ec41](https://github.com/argoproj/argo-workflows/commit/028f9ec41cf07056bfcf823a109964b00621797c) fix: Merge templateDefaults into dag task tmpl. Fixes #12821 (#12833)
+* [e8f0cae39](https://github.com/argoproj/argo-workflows/commit/e8f0cae398e8f135a6957cd74919368e0b692b6b) fix: Apply podSpecPatch  in `woc.execWf.Spec` and template to pod sequentially (#12476)
+* [c1a5f3073](https://github.com/argoproj/argo-workflows/commit/c1a5f3073c58033dcfba5d14fe3dff9092ab258d) fix: don't fail workflow if PDB creation fails (#13102)
+* [5c56a161c](https://github.com/argoproj/argo-workflows/commit/5c56a161cb66b1c83fc31e5238bb812bc35f9754) fix: Allow termination of workflow to update on exit handler nodes. fixes #13052 (#13120)
+* [e5dfe5d73](https://github.com/argoproj/argo-workflows/commit/e5dfe5d7393c04efc0e4067a02a37aae79231a64) fix: load missing fields for archived workflows (#13136)
+* [7dc7fc246](https://github.com/argoproj/argo-workflows/commit/7dc7fc246393295a53308df1b77c585d5b24fe07) fix(ui): `package.json#license` should be Apache (#13040)
+* [3622a896d](https://github.com/argoproj/argo-workflows/commit/3622a896d08599e0d325e739c9f389c399419f7d) fix(docs): Fix `gcloud` typo (#13101)
+* [207e0713a](https://github.com/argoproj/argo-workflows/commit/207e0713a6eae52fc7bd1e9dcb43206d55f1a754) docs(server): full copy-edit of auth mode page (#13137)
+
+### Contributors
+
+* Alan Clucas
+* Anton Gilgur
+* Janghun Lee(James)
+* Jiacheng Xu
+* Julie Vogelman
+* Miltiadis Alexis
+* Tianchu Zhao
+* Yulin Li
+* jswxstw
+
 ## v3.5.7 (2024-05-27)
 
 * [b2b1ecd7d](https://github.com/argoproj/argo-workflows/commit/b2b1ecd7de378cec31ab0ebb1e8b9665c4b05867) chore(deps): bump tj-actions/changed-files from 40 to 41 (#12433)

diff --git a/Dockerfile b/Dockerfile
@@ -3,7 +3,7 @@ ARG GIT_COMMIT=unknown
 ARG GIT_TAG=unknown
 ARG GIT_TREE_STATE=unknown
 
-FROM golang:1.21-alpine3.18 as builder
+FROM golang:1.21-alpine3.19 as builder
 
 RUN apk update && apk add --no-cache \
     git \

diff --git a/README.md b/README.md
@@ -1,5 +1,5 @@
 <!-- markdownlint-disable-next-line MD041 -->
-[![Security Status](https://github.com/argoproj/argo-workflows/workflows/Snyk/badge.svg)](https://github.com/argoproj/argo-workflows/actions/workflows/snyk.yml?query=branch%3Amain)
+[![Security Status](https://github.com/argoproj/argo-workflows/actions/workflows/snyk.yml/badge.svg?branch=release-3.5)](https://github.com/argoproj/argo-workflows/actions/workflows/snyk.yml?query=branch%3Arelease-3.5)
 [![OpenSSF Best Practices](https://bestpractices.coreinfrastructure.org/projects/3830/badge)](https://bestpractices.coreinfrastructure.org/projects/3830)
 [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/argoproj/argo-workflows/badge)](https://api.securityscorecards.dev/projects/github.com/argoproj/argo-workflows)
 [![FOSSA License Status](https://app.fossa.com/api/projects/git%2Bgithub.com%2Fargoproj%2Fargo-workflows.svg?type=shield)](https://app.fossa.com/projects/git%2Bgithub.com%2Fargoproj%2Fargo-workflows?ref=badge_shield)

diff --git a/cmd/argo/commands/lint_test.go b/cmd/argo/commands/lint_test.go
@@ -169,4 +169,45 @@ spec:
 
 		assert.False(t, fatal, "should not have exited")
 	})
+
+	workflowCaseSensitivePath := filepath.Join(subdir, "workflowCaseSensitive.yaml")
+	err = os.WriteFile(workflowCaseSensitivePath, []byte(`
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+  generateName: hello-world-
+spec:
+  entrypoInt: whalesay
+  templates:
+    - name: whalesay
+      container:
+        image: docker/whalesay
+        command: [ cowsay ]
+        args: [ "hello world" ]
+        resources:
+          limits:
+            memory: 32Mi
+            cpu: 100m
+`), 0644)
+	require.NoError(t, err)
+
+	t.Run("linting a workflow with case sensitive fields and strict enabled", func(t *testing.T) {
+		defer func() { logrus.StandardLogger().ExitFunc = nil }()
+		var fatal bool
+		logrus.StandardLogger().ExitFunc = func(int) { fatal = true }
+
+		runLint(context.Background(), []string{workflowCaseSensitivePath}, true, nil, "pretty", true)
+
+		assert.True(t, fatal, "should have exited")
+	})
+
+	t.Run("linting a workflow with case sensitive fields and strict disabled", func(t *testing.T) {
+		defer func() { logrus.StandardLogger().ExitFunc = nil }()
+		var fatal bool
+		logrus.StandardLogger().ExitFunc = func(int) { fatal = true }
+
+		runLint(context.Background(), []string{workflowCaseSensitivePath}, true, nil, "pretty", false)
+
+		assert.False(t, fatal, "should not have exited")
+	})
 }
diff --git a/docs/README.md b/docs/README.md
@@ -1,5 +1,5 @@
 <!-- markdownlint-disable-next-line MD041 -->
-[![Security Status](https://github.com/argoproj/argo-workflows/workflows/Snyk/badge.svg)](https://github.com/argoproj/argo-workflows/actions/workflows/snyk.yml?query=branch%3Amain)
+[![Security Status](https://github.com/argoproj/argo-workflows/actions/workflows/snyk.yml/badge.svg?branch=release-3.5)](https://github.com/argoproj/argo-workflows/actions/workflows/snyk.yml?query=branch%3Arelease-3.5)
 [![OpenSSF Best Practices](https://bestpractices.coreinfrastructure.org/projects/3830/badge)](https://bestpractices.coreinfrastructure.org/projects/3830)
 [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/argoproj/argo-workflows/badge)](https://api.securityscorecards.dev/projects/github.com/argoproj/argo-workflows)
 [![FOSSA License Status](https://app.fossa.com/api/projects/git%2Bgithub.com%2Fargoproj%2Fargo-workflows.svg?type=shield)](https://app.fossa.com/projects/git%2Bgithub.com%2Fargoproj%2Fargo-workflows?ref=badge_shield)

diff --git a/docs/cron-workflows.md b/docs/cron-workflows.md
@@ -2,13 +2,13 @@
 
 > v2.5 and after
 
-## Introduction
-
-`CronWorkflow` are workflows that run on a preset schedule. They are designed to be converted from `Workflow` easily and to mimic the same options as Kubernetes `CronJob`. In essence, `CronWorkflow` = `Workflow` + some specific cron options.
+`CronWorkflows` are workflows that run on a schedule.
+They are designed to wrap a `workflowSpec` and to mimic the options of Kubernetes `CronJobs`.
+In essence, `CronWorkflow` = `Workflow` + some specific cron options.
 
 ## `CronWorkflow` Spec
 
-An example `CronWorkflow` spec would look like:
+Below is an example `CronWorkflow`:
 
 ```yaml
 apiVersion: argoproj.io/v1alpha1
@@ -31,45 +31,49 @@ spec:
 
 ### `workflowSpec` and `workflowMetadata`
 
-`CronWorkflow.spec.workflowSpec` is the same type as `Workflow.spec` and serves as a template for `Workflow` objects that are created from it. Everything under this spec will be converted to a `Workflow`.
+`CronWorkflow.spec.workflowSpec` is the same type as `Workflow.spec`.
+It is a template for `Workflow` objects created from it.
 
-The resulting `Workflow` name will be a generated name based on the `CronWorkflow` name. In this example it could be something like `test-cron-wf-tj6fe`.
+The `Workflow` name is generated based on the `CronWorkflow` name.
+In the above example it would be similar to `test-cron-wf-tj6fe`.
 
-`CronWorkflow.spec.workflowMetadata` can be used to add `labels` and `annotations`.
+You can use `CronWorkflow.spec.workflowMetadata` to add `labels` and `annotations`.
 
 ### `CronWorkflow` Options
 
-|          Option Name         |      Default Value     | Description                                                                                                                                                                                                                             |
-|:----------------------------:|:----------------------:|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-|          `schedule`          | None, must be provided | Schedule at which the `Workflow` will be run. E.g. `5 4 * * *`                                                                                                                                                                         |
-|          `timezone`          |    Machine timezone    | Timezone during which the Workflow will be run from the IANA timezone standard, e.g. `America/Los_Angeles`                                                                                                                              |
-|           `suspend`          |         `false`        | If `true` Workflow scheduling will not occur. Can be set from the CLI, GitOps, or directly                                                                                                                                              |
-|      `concurrencyPolicy`     |         `Allow`        | Policy that determines what to do if multiple `Workflows` are scheduled at the same time. Available options: `Allow`: allow all, `Replace`: remove all old before scheduling a new, `Forbid`: do not allow any new while there are old  |
-| `startingDeadlineSeconds`    |           `0`          | Number of seconds after the last successful run during which a missed `Workflow` will be run                                                                                                                                            |
-| `successfulJobsHistoryLimit` |           `3`          | Number of successful `Workflows` that will be persisted at a time                                                                                                                                                                       |
-| `failedJobsHistoryLimit`     | `1`                    | Number of failed `Workflows` that will be persisted at a time                                                                                                                                                                           |
+| Option Name                  | Default Value          | Description |
+|:----------------------------:|:----------------------:|-------------|
+| `schedule`                   | None, must be provided | [Cron schedule](#cron-schedule-syntax) to run `Workflows`. Example: `5 4 * * *` |
+| `timezone`                   | Machine timezone       | [IANA Timezone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) to run `Workflows`. Example: `America/Los_Angeles` |
+| `suspend`                    | `false`                | If `true` Workflow scheduling will not occur. Can be set from the CLI, GitOps, or directly |
+| `concurrencyPolicy`          | `Allow`                | What to do if multiple `Workflows` are scheduled at the same time. `Allow`: allow all, `Replace`: remove all old before scheduling new, `Forbid`: do not allow any new while there are old  |
+| `startingDeadlineSeconds`    | `0`                    | Seconds after [the last scheduled time](#crash-recovery) during which a missed `Workflow` will still be run. |
+| `successfulJobsHistoryLimit` | `3`                    | Number of successful `Workflows` to persist |
+| `failedJobsHistoryLimit`     | `1`                    | Number of failed `Workflows` to persist |
 
 ### Cron Schedule Syntax
 
-The cron scheduler uses the standard cron syntax, as [documented on Wikipedia](https://en.wikipedia.org/wiki/Cron).
-
-More detailed documentation for the specific library used is [documented here](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
+The cron scheduler uses [standard cron syntax](https://en.wikipedia.org/wiki/Cron).
+The implementation is the same as `CronJobs`, using [`robfig/cron`](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
 
 ### Crash Recovery
 
-If the `workflow-controller` crashes (and hence the `CronWorkflow` controller), there are some options you can set to ensure that `CronWorkflows` that would have been scheduled while the controller was down can still run. Mainly `startingDeadlineSeconds` can be set to specify the maximum number of seconds past the last successful run of a `CronWorkflow` during which a missed run will still be executed.
+If the Controller crashes, you can ensure that any missed schedules still run.
 
-For example, if a `CronWorkflow` that runs every minute is last run at 12:05:00, and the controller crashes between 12:05:55 and 12:06:05, then the expected execution time of 12:06:00 would be missed. However, if `startingDeadlineSeconds` is set to a value greater than 65 (the amount of time passing between the last scheduled run time of 12:05:00 and the current controller restart time of 12:06:05), then a single instance of the `CronWorkflow` will be executed exactly at 12:06:05.
+With `startingDeadlineSeconds` you can specify a maximum grace period past the last scheduled time during which it will still run.
+For example, if a `CronWorkflow` that runs every minute is last run at 12:05:00, and the controller crashes between 12:05:55 and 12:06:05, then the expected execution time of 12:06:00 would be missed.
+However, if `startingDeadlineSeconds` is set to a value greater than 5 (the time passed between the last scheduled time of 12:06:00 and the current time of 12:06:05), then a single instance of the `CronWorkflow` will be executed exactly at 12:06:05.
 
 Currently only a single instance will be executed as a result of setting `startingDeadlineSeconds`.
 
 This setting can also be configured in tandem with `concurrencyPolicy` to achieve more fine-tuned control.
 
 ### Daylight Saving
 
-Daylight Saving (DST) is taken into account when using timezone. This means that, depending on the local time of the scheduled job, argo will schedule the workflow once, twice, or not at all when the clock moves forward or back.
+When using `timezone`, [Daylight Saving Time (DST)](https://en.wikipedia.org/wiki/Daylight_saving_time) is taken into account.
+Depending on the local time of the scheduled workflow, it will run once, twice, or not at all when the clock moves forward or back.
 
-For example, with timezone set at `America/Los_Angeles`, we have daylight saving
+For example, with `timezone: America/Los_Angeles`:
 
 - +1 hour (DST start) at 2020-03-08 02:00:00:
 
@@ -107,7 +111,7 @@ For example, with timezone set at `America/Los_Angeles`, we have daylight saving
 
 ### CLI
 
-`CronWorkflow` can be created from the CLI by using basic commands:
+You can create `CronWorkflows` with the CLI:
 
 ```bash
 $ argo cron create cron.yaml
@@ -142,20 +146,20 @@ NextScheduledTime:             Thu Oct 29 13:03:00 +0000 (32 seconds from now)
 Active Workflows:              test-cron-wf-rt4nf
 ```
 
-**Note**: `NextScheduledRun` assumes that the workflow-controller uses UTC as its timezone
+**Note**: `NextScheduledRun` assumes the Controller uses UTC as its timezone
 
 ### `kubectl`
 
-Using `kubectl apply -f` and `kubectl get cwf`
+You can use `kubectl apply -f` and `kubectl get cwf`
 
 ## Back-Filling Days
 
 See [cron backfill](cron-backfill.md).
 
 ### GitOps via Argo CD
 
-`CronWorkflow` resources can be managed with GitOps by using [Argo CD](https://github.com/argoproj/argo-cd)
+You can manage `CronWorkflow` resources with GitOps by using [Argo CD](https://github.com/argoproj/argo-cd)
 
 ### UI
 
-`CronWorkflow` resources can also be managed by the UI
+You can also manage `CronWorkflow` resources in the UI