Skip to content

Commit

Permalink
Merge pull request #347 from codefresh-io/sec-vuln-sync
Browse files Browse the repository at this point in the history 
chore: sync `v.3.5.9` into our fork
  • Loading branch information
@ATGardner
ATGardner authored Jul 31, 2024
2 parents 3a69e55 + 2f9cd8c commit 2891faa
Show file tree
Hide file tree
Showing 55 changed files with 917 additions and 341 deletions.
7 changes: 7 additions & 0 deletions .snyk
View file
Original file line number Diff line number Diff line change
@@ -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
28 changes: 28 additions & 0 deletions CHANGELOG.md
View file
Original file line number Diff line number Diff line change
@@ -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)
Expand Down
2 changes: 1 addition & 1 deletion Dockerfile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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 \
Expand Down
2 changes: 1 addition & 1 deletion README.md
View file
Original file line number Diff line number Diff line change
@@ -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)
Expand Down
41 changes: 41 additions & 0 deletions cmd/argo/commands/lint_test.go
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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")
})
}
2 changes: 1 addition & 1 deletion docs/README.md
View file
Original file line number Diff line number Diff line change
@@ -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)
Expand Down
60 changes: 32 additions & 28 deletions docs/cron-workflows.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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:

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Loading

0 comments on commit 2891faa

Please sign in to comment.