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
Copy file name to clipboardExpand all lines: CHANGELOG.md
+28Lines changed: 28 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,33 @@
1
1
# Changelog
2
2
3
+
## v3.5.8 (2024-06-17)
4
+
5
+
* [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)
6
+
* [10488d655](https://github.com/argoproj/argo-workflows/commit/10488d655a78c28bb6e3e6bca490a5496addd605) fix: don't necessarily include all artifacts from templates in node outputs (#13066)
7
+
* [c2204ae03](https://github.com/argoproj/argo-workflows/commit/c2204ae03de97acf1c589c898180bdb9942f1524) fix(server): don't use cluster scope list + watch in namespaced mode. Fixes #13177 (#13189)
8
+
* [9481bb04c](https://github.com/argoproj/argo-workflows/commit/9481bb04c3e48a85da5ba05ef47c2f0a2ba500f4) fix(server): mutex calls to sqlitex (#13166)
9
+
* [ee150afdf](https://github.com/argoproj/argo-workflows/commit/ee150afdf3561f8250c5212e1b6a38628a847b39) fix: only evaluate retry expression for fail/error node. Fixes #13058 (#13165)
10
+
* [028f9ec41](https://github.com/argoproj/argo-workflows/commit/028f9ec41cf07056bfcf823a109964b00621797c) fix: Merge templateDefaults into dag task tmpl. Fixes #12821 (#12833)
11
+
* [e8f0cae39](https://github.com/argoproj/argo-workflows/commit/e8f0cae398e8f135a6957cd74919368e0b692b6b) fix: Apply podSpecPatch in `woc.execWf.Spec` and template to pod sequentially (#12476)
* [5c56a161c](https://github.com/argoproj/argo-workflows/commit/5c56a161cb66b1c83fc31e5238bb812bc35f9754) fix: Allow termination of workflow to update on exit handler nodes. fixes #13052 (#13120)
14
+
* [e5dfe5d73](https://github.com/argoproj/argo-workflows/commit/e5dfe5d7393c04efc0e4067a02a37aae79231a64) fix: load missing fields for archived workflows (#13136)
15
+
* [7dc7fc246](https://github.com/argoproj/argo-workflows/commit/7dc7fc246393295a53308df1b77c585d5b24fe07) fix(ui): `package.json#license` should be Apache (#13040)
* [207e0713a](https://github.com/argoproj/argo-workflows/commit/207e0713a6eae52fc7bd1e9dcb43206d55f1a754) docs(server): full copy-edit of auth mode page (#13137)
18
+
19
+
### Contributors
20
+
21
+
* Alan Clucas
22
+
* Anton Gilgur
23
+
* Janghun Lee(James)
24
+
* Jiacheng Xu
25
+
* Julie Vogelman
26
+
* Miltiadis Alexis
27
+
* Tianchu Zhao
28
+
* Yulin Li
29
+
* jswxstw
30
+
3
31
## v3.5.7 (2024-05-27)
4
32
5
33
* [b2b1ecd7d](https://github.com/argoproj/argo-workflows/commit/b2b1ecd7de378cec31ab0ebb1e8b9665c4b05867) chore(deps): bump tj-actions/changed-files from 40 to 41 (#12433)
[](https://bestpractices.coreinfrastructure.org/projects/3830)
[](https://bestpractices.coreinfrastructure.org/projects/3830)
Copy file name to clipboardExpand all lines: docs/cron-workflows.md
+32-28Lines changed: 32 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,13 @@
2
2
3
3
> v2.5 and after
4
4
5
-
## Introduction
6
-
7
-
`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.
5
+
`CronWorkflows` are workflows that run on a schedule.
6
+
They are designed to wrap a `workflowSpec` and to mimic the options of Kubernetes `CronJobs`.
7
+
In essence, `CronWorkflow` = `Workflow` + some specific cron options.
8
8
9
9
## `CronWorkflow` Spec
10
10
11
-
An example `CronWorkflow` spec would look like:
11
+
Below is an example `CronWorkflow`:
12
12
13
13
```yaml
14
14
apiVersion: argoproj.io/v1alpha1
@@ -31,45 +31,49 @@ spec:
31
31
32
32
### `workflowSpec` and `workflowMetadata`
33
33
34
-
`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`.
34
+
`CronWorkflow.spec.workflowSpec`is the same type as `Workflow.spec`.
35
+
It is a template for `Workflow` objects created from it.
35
36
36
-
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`.
37
+
The `Workflow` name is generated based on the `CronWorkflow` name.
38
+
In the above example it would be similar to `test-cron-wf-tj6fe`.
37
39
38
-
`CronWorkflow.spec.workflowMetadata`can be used to add `labels` and `annotations`.
40
+
You can use `CronWorkflow.spec.workflowMetadata` to add `labels` and `annotations`.
| `schedule` | None, must be provided | Schedule at which the `Workflow` will be run. E.g. `5 4 * * *` |
45
-
| `timezone` |Machine timezone | Timezone during which the Workflow will be run from the IANA timezone standard, e.g. `America/Los_Angeles` |
46
-
| `suspend` | `false` | If `true` Workflow scheduling will not occur. Can be set from the CLI, GitOps, or directly |
47
-
| `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 |
48
-
| `startingDeadlineSeconds` | `0` | Number of seconds after the last successful run during which a missed `Workflow` will be run |
49
-
| `successfulJobsHistoryLimit` | `3` | Number of successful `Workflows` that will be persisted at a time |
50
-
| `failedJobsHistoryLimit` | `1` | Number of failed `Workflows` that will be persisted at a time |
| `schedule` | None, must be provided | [Cron schedule](#cron-schedule-syntax) to run `Workflows`. Example: `5 4 * * *` |
47
+
| `timezone` | Machine timezone | [IANA Timezone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) to run `Workflows`. Example: `America/Los_Angeles`|
48
+
| `suspend` | `false` | If `true` Workflow scheduling will not occur. Can be set from the CLI, GitOps, or directly |
49
+
| `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 |
50
+
| `startingDeadlineSeconds` | `0` | Seconds after [the last scheduled time](#crash-recovery) during which a missed `Workflow` will still be run. |
51
+
| `successfulJobsHistoryLimit` | `3` | Number of successful `Workflows` to persist |
52
+
| `failedJobsHistoryLimit` | `1` | Number of failed `Workflows` to persist |
51
53
52
54
### Cron Schedule Syntax
53
55
54
-
The cron scheduler uses the standard cron syntax, as [documented on Wikipedia](https://en.wikipedia.org/wiki/Cron).
55
-
56
-
More detailed documentation for the specific library used is [documented here](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
56
+
The cron scheduler uses [standard cron syntax](https://en.wikipedia.org/wiki/Cron).
57
+
The implementation is the same as `CronJobs`, using [`robfig/cron`](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
57
58
58
59
### Crash Recovery
59
60
60
-
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.
61
+
If the Controller crashes, you can ensure that any missed schedules still run.
61
62
62
-
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.
63
+
With `startingDeadlineSeconds` you can specify a maximum grace period past the last scheduled time during which it will still run.
64
+
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.
65
+
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.
63
66
64
67
Currently only a single instance will be executed as a result of setting `startingDeadlineSeconds`.
65
68
66
69
This setting can also be configured in tandem with `concurrencyPolicy` to achieve more fine-tuned control.
67
70
68
71
### Daylight Saving
69
72
70
-
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.
73
+
When using `timezone`, [Daylight Saving Time (DST)](https://en.wikipedia.org/wiki/Daylight_saving_time) is taken into account.
74
+
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.
71
75
72
-
For example, with timezone set at `America/Los_Angeles`, we have daylight saving
76
+
For example, with `timezone: America/Los_Angeles`:
73
77
74
78
- +1 hour (DST start) at 2020-03-08 02:00:00:
75
79
@@ -107,7 +111,7 @@ For example, with timezone set at `America/Los_Angeles`, we have daylight saving
107
111
108
112
### CLI
109
113
110
-
`CronWorkflow` can be created from the CLI by using basic commands:
114
+
You can create `CronWorkflows` with the CLI:
111
115
112
116
```bash
113
117
$ argo cron create cron.yaml
@@ -142,20 +146,20 @@ NextScheduledTime: Thu Oct 29 13:03:00 +0000 (32 seconds from now)
142
146
Active Workflows: test-cron-wf-rt4nf
143
147
```
144
148
145
-
**Note**: `NextScheduledRun` assumes that the workflow-controller uses UTC as its timezone
149
+
**Note**: `NextScheduledRun` assumes the Controller uses UTC as its timezone
146
150
147
151
### `kubectl`
148
152
149
-
Using `kubectl apply -f` and `kubectl get cwf`
153
+
You can use `kubectl apply -f` and `kubectl get cwf`
150
154
151
155
## Back-Filling Days
152
156
153
157
See [cron backfill](cron-backfill.md).
154
158
155
159
### GitOps via Argo CD
156
160
157
-
`CronWorkflow`resources can be managed with GitOps by using [Argo CD](https://github.com/argoproj/argo-cd)
161
+
You can manage `CronWorkflow` resources with GitOps by using [Argo CD](https://github.com/argoproj/argo-cd)
158
162
159
163
### UI
160
164
161
-
`CronWorkflow`resources can also be managed by the UI
165
+
You can also manage `CronWorkflow` resources in the UI
0 commit comments