Deprecate secrets (#4235)

This commit is contained in:
qwerty287 2024-10-24 08:36:29 +03:00 committed by GitHub
parent 1b5ee05307
commit 49e40772ca
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
7 changed files with 28 additions and 35 deletions

View file

@ -179,12 +179,6 @@ Woodpecker provides the ability to pass environment variables to individual step
For more details, check the [environment docs](./50-environment.md).
### `secrets`
Woodpecker provides the ability to store named parameters external to the YAML configuration file, in a central secret store. These secrets can be passed to individual steps of the workflow at runtime.
For more details, check the [secrets docs](./40-secrets.md).
### `failure`
Some of the steps may be allowed to fail without causing the whole workflow and therefore pipeline to report a failure (e.g., a step executing a linting check). To enable this, add `failure: ignore` to your step. If Woodpecker encounters an error while executing the step, it will report it as failed but still executes the next steps of the workflow, if any, without affecting the status of the workflow.

View file

@ -11,26 +11,7 @@ Woodpecker provides three different levels to add secrets to your pipeline. The
## Usage
### Use secrets in commands
Secrets are exposed to your pipeline steps and plugins as uppercase environment variables and can therefore be referenced in the commands section of your pipeline,
once their usage is declared in the `secrets` section:
```diff
steps:
- name: docker
image: docker
commands:
+ - echo $docker_username
+ - echo $DOCKER_PASSWORD
+ secrets: [ docker_username, DOCKER_PASSWORD ]
```
The case of the environment variables is not changed, but secret matching is done case-insensitively. In the example above, `DOCKER_PASSWORD` would also match if the secret is called `docker_password`.
### Use secrets in settings and environment
You can set an setting or environment value from secrets using the `from_secret` syntax.
You can set a setting or an environment value from secrets using the `from_secret` syntax.
In this example, the secret named `secret_token` would be passed to the setting named `token`,which will be available in the plugin as environment variable named `PLUGIN_TOKEN` (See [plugins](./51-plugins/20-creating-plugins.md#settings) for details), and to the environment variable `TOKEN_ENV`.
@ -55,11 +36,11 @@ Please note parameter expressions are subject to pre-processing. When using secr
- name: docker
image: docker
commands:
- - echo ${docker_username}
- - echo ${DOCKER_PASSWORD}
+ - echo $${docker_username}
+ - echo $${DOCKER_PASSWORD}
secrets: [ docker_username, DOCKER_PASSWORD ]
- - echo ${TOKEN_ENV}
+ - echo $${TOKEN_ENV}
environment:
TOKEN_ENV:
from_secret: secret_token
```
### Use in Pull Requests events

View file

@ -42,7 +42,7 @@ Values like this are converted to JSON and then passed to your plugin. In the ex
### Secrets
Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-settings-and-environment).
Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#usage).
## Plugin library

View file

@ -52,7 +52,7 @@ While normal steps are all about arbitrary code execution, plugins should only a
That's why there are a few limitations. The workspace base is always mounted at `/woodpecker`, but the working directory is dynamically
adjusted accordingly, as user of a plugin you should not have to care about this. Also, you cannot use the plugin together with `commands`
or `entrypoint` which will fail. Using `secrets` or `environment` is possible, but in this case, the plugin is internally not treated as plugin
or `entrypoint` which will fail. Using `environment` is possible, but in this case, the plugin is internally not treated as plugin
anymore. The container then cannot access secrets with plugin filter anymore and the containers won't be privileged without explicit definition.
## Finding Plugins

View file

@ -25,7 +25,7 @@ Some versions need some changes to the server configuration or the pipeline conf
- Pipelines without a config file will now be skipped instead of failing
- Removed implicitly defined `regcred` image pull secret name. Set it explicitly via `WOODPECKER_BACKEND_K8S_PULL_SECRET_NAMES`
- Removed `includes` and `excludes` support from **event** filter
- Removed uppercasing all secret env vars, instead, the value of the `secrets` property is used. [Read more](./20-usage/40-secrets.md#use-secrets-in-commands)
- Removed uppercasing all secret env vars, instead, the value of the `secrets` property is used. [Read more](./20-usage/40-secrets.md#usage)
- Removed alternative names for secrets, use `environment` with `from_secret`
- Removed slice definition for env vars
- Removed `environment` filter, use `when.evaluate`
@ -38,6 +38,7 @@ Some versions need some changes to the server configuration or the pipeline conf
- Removed old API routes: `registry/` -> `registries`, `/authorize/token`
- Replaced `registry` command with `repo registry` in cli
- Disallow upgrades from 1.x, upgrade to 2.x first
- Deprecated `secrets`, use `environment` with `from_secret`
## 2.0.0

View file

@ -265,6 +265,21 @@ func (l *Linter) lintDeprecations(config *WorkflowConfig) (err error) {
return err
}
for _, container := range parsed.Steps.ContainerList {
if len(container.Secrets) > 0 {
err = multierr.Append(err, &errorTypes.PipelineError{
Type: errorTypes.PipelineErrorTypeDeprecation,
Message: "Secrets are deprecated, use environment with from_secret",
Data: errors.DeprecationErrorData{
File: config.File,
Field: fmt.Sprintf("steps.%s.secrets", container.Name),
Docs: "https://woodpecker-ci.org/docs/usage/secrets#usage",
},
IsWarning: true,
})
}
}
return nil
}

View file

@ -47,9 +47,11 @@ type (
Ports []string `yaml:"ports,omitempty"`
DependsOn base.StringOrSlice `yaml:"depends_on,omitempty"`
Secrets []string `yaml:"secrets,omitempty"`
Environment map[string]any `yaml:"environment,omitempty"`
// Deprecated
Secrets []string `yaml:"secrets,omitempty"`
// Docker and Kubernetes Specific
Privileged bool `yaml:"privileged,omitempty"`