Skip to content

Commit

Permalink
chore: merge master
Browse files Browse the repository at this point in the history
Signed-off-by: Gallardot <[email protected]>
  • Loading branch information
Gallardot committed Nov 27, 2022
1 parent 728bbe9 commit a7cb37e
Show file tree
Hide file tree
Showing 21 changed files with 1,254 additions and 522 deletions.
2 changes: 1 addition & 1 deletion .github/workflows/go.yml
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ jobs:
uses: golangci/golangci-lint-action@v3
with:
version: v1.49.0
args: --timeout 5m
args: --timeout 6m
build:
name: Build
runs-on: ubuntu-latest
Expand Down
6 changes: 6 additions & 0 deletions docs/features/specification.md
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,12 @@ spec:
# than or equal to this value.
restartAt: "2020-03-30T21:19:35Z"

# The rollback window provides a way to fast track deployments to
# previously deployed versions.
# Optional, and by default is not set.
rollbackWindow:
revisions: 3

strategy:

# Blue-green update strategy
Expand Down
23 changes: 23 additions & 0 deletions docs/rollback.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Rollback Windows

!!! important

Available for blue-green and canary rollouts since v1.4

By default, when an older Rollout manifest is re-applied, the controller treats it the same as a spec change, and will execute the full list of steps, and perform analysis too. There are two exceptions to this rule:
1. the controller detects if it is moving back to a blue-green ReplicaSet which exists and is still scaled up (within its `scaleDownDelay`)
2. the controller detects it is moving back to the canary's "stable" ReplicaSet, and the upgrade had not yet completed.

It is often undesirable to re-run analysis and steps for a rollout, when the desired behavior is to rollback as soon as possible. To help with this, a rollback window feature allows users to indicate that the promotion to the ReplicaSet within the window will skip all steps.

Example:

```yaml
spec:
rollbackWindow:
revisions: 3

revisionHistoryLimit: 5
```
Assume a linear revision history: `1`, `2`, `3`, `4`, `5 (current)`. A rollback from revision 5 back to 4 or 3 will fall within the window, so it will be fast tracked.
6 changes: 6 additions & 0 deletions manifests/crds/rollout-crd.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,12 @@ spec:
revisionHistoryLimit:
format: int32
type: integer
rollbackWindow:
properties:
revisions:
format: int32
type: integer
type: object
selector:
properties:
matchExpressions:
Expand Down
6 changes: 6 additions & 0 deletions manifests/install.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -11089,6 +11089,12 @@ spec:
revisionHistoryLimit:
format: int32
type: integer
rollbackWindow:
properties:
revisions:
format: int32
type: integer
type: object
selector:
properties:
matchExpressions:
Expand Down
6 changes: 6 additions & 0 deletions manifests/namespace-install.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -11089,6 +11089,12 @@ spec:
revisionHistoryLimit:
format: int32
type: integer
rollbackWindow:
properties:
revisions:
format: int32
type: integer
type: object
selector:
properties:
matchExpressions:
Expand Down
1 change: 1 addition & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@ nav:
- Ephemeral Metadata: features/ephemeral-metadata.md
- Restarting Rollouts: features/restart.md
- Scaledown Aborted Rollouts: features/scaledown-aborted-rs.md
- Rollback Window: features/rollback.md
- Anti Affinity: features/anti-affinity/anti-affinity.md
- Helm: features/helm.md
- Kustomize: features/kustomize.md
Expand Down
13 changes: 13 additions & 0 deletions pkg/apiclient/rollout/rollout.swagger.json
Original file line number Diff line number Diff line change
Expand Up @@ -1143,6 +1143,15 @@
"type": "object",
"title": "RequiredDuringSchedulingIgnoredDuringExecution defines inter-pod scheduling rule to be RequiredDuringSchedulingIgnoredDuringExecution"
},
"github.com.argoproj.argo_rollouts.pkg.apis.rollouts.v1alpha1.RollbackWindowSpec": {
"type": "object",
"properties": {
"revisions": {
"type": "integer",
"format": "int32"
}
}
},
"github.com.argoproj.argo_rollouts.pkg.apis.rollouts.v1alpha1.Rollout": {
"type": "object",
"properties": {
Expand Down Expand Up @@ -1382,6 +1391,10 @@
"format": "int32",
"title": "Minimum number of seconds for which a newly created pod should be ready\nwithout any of its container crashing, for it to be considered available.\nDefaults to 0 (pod will be considered available as soon as it is ready)\n+optional"
},
"rollbackWindow": {
"$ref": "#/definitions/github.com.argoproj.argo_rollouts.pkg.apis.rollouts.v1alpha1.RollbackWindowSpec",
"title": "The window in which a rollback will be fast tracked (fully promoted)\n+optional"
},
"strategy": {
"$ref": "#/definitions/github.com.argoproj.argo_rollouts.pkg.apis.rollouts.v1alpha1.RolloutStrategy",
"title": "The deployment strategy to use to replace existing pods with new ones.\n+optional"
Expand Down
Loading

0 comments on commit a7cb37e

Please sign in to comment.