mirror of
https://github.com/woodpecker-ci/woodpecker.git
synced 2024-11-25 11:21:02 +00:00
Deprecate secrets
(#4235)
This commit is contained in:
parent
1b5ee05307
commit
49e40772ca
7 changed files with 28 additions and 35 deletions
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
}
|
||||
|
||||
|
|
|
@ -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"`
|
||||
|
||||
|
|
Loading…
Reference in a new issue