woodpecker/docs/docs/30-administration/10-server-config.md

561 lines
14 KiB
Markdown
Raw Normal View History

---
toc_max_heading_level: 2
---
# Server configuration
## User registration
Woodpecker does not have its own user registry; users are provided from your [forge](./11-forges/11-overview.md) (using OAuth2).
Registration is closed by default (`WOODPECKER_OPEN=false`). If registration is open (`WOODPECKER_OPEN=true`) then every user with an account at the configured forge can login to Woodpecker.
To open registration:
```ini
WOODPECKER_OPEN=true
```
You can **also restrict** registration, by keep registration closed and:
- **adding** new **users manually** via the CLI: `woodpecker-cli user add`
- allowing specific **admin users** via the `WOODPECKER_ADMIN` setting
- by open registration and **filter by organization** membership through the `WOODPECKER_ORGS` setting
### Close registration, but allow specific admin users
```ini
WOODPECKER_OPEN=false
WOODPECKER_ADMIN=johnsmith,janedoe
```
### Only allow registration of users, who are members of approved organizations
```ini
WOODPECKER_OPEN=true
WOODPECKER_ORGS=dolores,dogpatch
```
## Administrators
Administrators should also be enumerated in your configuration.
```ini
WOODPECKER_ADMIN=johnsmith,janedoe
```
## Filtering repositories
Woodpecker operates with the user's OAuth permission. Due to the coarse permission handling of GitHub, you may end up syncing more repos into Woodpecker than preferred.
Use the `WOODPECKER_REPO_OWNERS` variable to filter which GitHub user's repos should be synced only. You typically want to put here your company's GitHub name.
```ini
WOODPECKER_REPO_OWNERS=mycompany,mycompanyossgithubuser
```
## Global registry setting
If you want to make available a specific private registry to all pipelines, use the `WOODPECKER_DOCKER_CONFIG` server configuration.
Point it to your server's docker config.
```ini
WOODPECKER_DOCKER_CONFIG=/root/.docker/config.json
```
## Handling sensitive data in docker-compose and docker-swarm
To handle sensitive data in docker-compose or docker-swarm configurations there are several options:
For docker-compose you can use a `.env` file next to your compose configuration to store the secrets outside of the compose file. While this separates configuration from secrets it is still not very secure.
Alternatively use docker-secrets. As it may be difficult to use docker secrets for environment variables Woodpecker allows to read sensible data from files by providing a `*_FILE` option of all sensible configuration variables. Woodpecker will try to read the value directly from this file. Keep in mind that when the original environment variable gets specified at the same time it will override the value read from the file.
```diff title="docker-compose.yaml"
version: '3'
services:
woodpecker-server:
[...]
environment:
- [...]
+ - WOODPECKER_AGENT_SECRET_FILE=/run/secrets/woodpecker-agent-secret
+ secrets:
+ - woodpecker-agent-secret
+
+ secrets:
+ woodpecker-agent-secret:
+ external: true
```
Store a value to a docker secret like this:
```bash
echo "my_agent_secret_key" | docker secret create woodpecker-agent-secret -
```
or generate a random one like this:
```bash
openssl rand -hex 32 | docker secret create woodpecker-agent-secret -
```
## Custom JavaScript and CSS
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
Woodpecker supports custom JS and CSS files.
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
These files must be present in the server's filesystem.
They can be backed in a Docker image or mounted from a ConfigMap inside a Kubernetes environment.
The configuration variables are independent of each other, which means it can be just one file present, or both.
```ini
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
WOODPECKER_CUSTOM_CSS_FILE=/usr/local/www/woodpecker.css
WOODPECKER_CUSTOM_JS_FILE=/usr/local/www/woodpecker.js
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
```
The examples below show how to place a banner message in the top navigation bar of Woodpecker.
### `woodpecker.css`
2023-10-24 12:42:05 +00:00
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
```css
.banner-message {
2023-10-24 12:42:05 +00:00
position: absolute;
width: 280px;
height: 40px;
margin-left: 240px;
margin-top: 5px;
padding-top: 5px;
font-weight: bold;
background: red no-repeat;
text-align: center;
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
}
```
### `woodpecker.js`
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
```javascript
// place/copy a minified version of jQuery or ZeptoJS here ...
2023-10-24 12:42:05 +00:00
!(function () {
'use strict';
function e() {} /*...*/
})();
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
2023-10-24 12:42:05 +00:00
$().ready(function () {
$('.app nav img').first().htmlAfter("<div class='banner-message'>This is a demo banner message :)</div>");
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
});
```
## All server configuration options
The following list describes all available server configuration options.
### `WOODPECKER_LOG_LEVEL`
2023-10-24 12:42:05 +00:00
> Default: empty
Configures the logging level. Possible values are `trace`, `debug`, `info`, `warn`, `error`, `fatal`, `panic`, `disabled` and empty.
### `WOODPECKER_LOG_FILE`
> Default: `stderr`
Output destination for logs.
'stdout' and 'stderr' can be used as special keywords.
### `WOODPECKER_LOG_XORM`
2023-10-24 12:42:05 +00:00
> Default: `false`
Enable XORM logs.
### `WOODPECKER_LOG_XORM_SQL`
2023-10-24 12:42:05 +00:00
> Default: `false`
Enable XORM SQL command logs.
### `WOODPECKER_DEBUG_PRETTY`
2023-10-24 12:42:05 +00:00
> Default: `false`
Enable pretty-printed debug output.
### `WOODPECKER_DEBUG_NOCOLOR`
2023-10-24 12:42:05 +00:00
> Default: `true`
Disable colored debug output.
### `WOODPECKER_HOST`
2023-10-24 12:42:05 +00:00
> Default: empty
2024-01-22 07:18:50 +00:00
Server fully qualified URL of the user-facing hostname, port (if not default for HTTP/HTTPS) and path prefix.
2024-01-22 07:18:50 +00:00
Examples:
- `WOODPECKER_HOST=http://woodpecker.example.org`
- `WOODPECKER_HOST=http://example.org/woodpecker`
- `WOODPECKER_HOST=http://example.org:1234/woodpecker`
### `WOODPECKER_WEBHOOK_HOST`
2023-10-24 12:42:05 +00:00
> Default: value from `WOODPECKER_HOST` config env
Server fully qualified URL of the Webhook-facing hostname and path prefix.
Example: `WOODPECKER_WEBHOOK_HOST=http://woodpecker-server.cicd.svc.cluster.local:8000`
### `WOODPECKER_SERVER_ADDR`
2023-10-24 12:42:05 +00:00
> Default: `:8000`
Configures the HTTP listener port.
### `WOODPECKER_SERVER_ADDR_TLS`
2023-10-24 12:42:05 +00:00
> Default: `:443`
Configures the HTTPS listener port when SSL is enabled.
### `WOODPECKER_SERVER_CERT`
2023-10-24 12:42:05 +00:00
> Default: empty
Path to an SSL certificate used by the server to accept HTTPS requests.
Example: `WOODPECKER_SERVER_CERT=/path/to/cert.pem`
### `WOODPECKER_SERVER_KEY`
2023-10-24 12:42:05 +00:00
> Default: empty
Path to an SSL certificate key used by the server to accept HTTPS requests.
Example: `WOODPECKER_SERVER_KEY=/path/to/key.pem`
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
### `WOODPECKER_CUSTOM_CSS_FILE`
2023-10-24 12:42:05 +00:00
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
> Default: empty
File path for the server to serve a custom .CSS file, used for customizing the UI.
Can be used for showing banner messages, logos, or environment-specific hints (a.k.a. white-labeling).
The file must be UTF-8 encoded, to ensure all special characters are preserved.
Example: `WOODPECKER_CUSTOM_CSS_FILE=/usr/local/www/woodpecker.css`
### `WOODPECKER_CUSTOM_JS_FILE`
2023-10-24 12:42:05 +00:00
support custom .JS and .CSS files for custom banner messages (white-labeling) (#1781) This PR introduces two new server configuration options, for providing a custom .JS and .CSS file. These can be used to show custom banner messages, add environment-dependent signals, or simply a corporate logo. ### Motivation (what problem I try to solve) I'm operating Woodpecker in multiple k8s clusters for different environments. When having multiple browser tabs open, I prefer strong indicators for each environment. E.g. a red "PROD" banner, or just a blue "QA" banner. Also, we sometimes need to have the chance for maintenance, and instead of broadcasting emails, I prefer a banner message, stating something like: "Heads-up: there's a planned downtime, next Friday, blabla...". Also, I like to have the firm's logo visible, which makes Woodpecker look more like an integral part of our platform. ### Implementation notes * Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE``` and ```WOODPECKER_CUSTOM_JS_FILE``` * I've piggy-bagged the existing handler for assets, as it seemed to me a minimally invasive approach * the option along with an example is documented * a simple unit test for the Gin-handler ensures some regression safety * no extra dependencies are introduced ### Visual example The documented example will look like this. ![Screenshot 2023-05-27 at 17 00 44](https://github.com/woodpecker-ci/woodpecker/assets/1189394/8940392e-463c-4651-a1eb-f017cd3cd64d) ### Areas of uncertainty This is my first contribution to Woodpecker and I tried my best to align with your conventions. That said, I found myself uncertain about these things and would be glad about getting feedback. * The handler tests are somewhat different than the other ones because I wanted to keep them simple - I hope that still matches your coding guidelines * caching the page sometimes will let the browser not recognize changes and a user must reload. I'm not fully into the details of how caching is implemented and neither can judge if it's a real problem. Another pair of eyes would be good.
2023-07-10 10:46:35 +00:00
> Default: empty
File path for the server to serve a custom .JS file, used for customizing the UI.
Can be used for showing banner messages, logos, or environment-specific hints (a.k.a. white-labeling).
The file must be UTF-8 encoded, to ensure all special characters are preserved.
Example: `WOODPECKER_CUSTOM_JS_FILE=/usr/local/www/woodpecker.js`
### `WOODPECKER_LETS_ENCRYPT`
2023-10-24 12:42:05 +00:00
> Default: `false`
Automatically generates an SSL certificate using Let's Encrypt, and configures the server to accept HTTPS requests.
### `WOODPECKER_GRPC_ADDR`
2023-10-24 12:42:05 +00:00
> Default: `:9000`
Configures the gRPC listener port.
### `WOODPECKER_GRPC_SECRET`
2023-10-24 12:42:05 +00:00
> Default: `secret`
Configures the gRPC JWT secret.
### `WOODPECKER_GRPC_SECRET_FILE`
2023-10-24 12:42:05 +00:00
> Default: empty
Read the value for `WOODPECKER_GRPC_SECRET` from the specified filepath.
### `WOODPECKER_METRICS_SERVER_ADDR`
2023-10-24 12:42:05 +00:00
> Default: empty
Configures an unprotected metrics endpoint. An empty value disables the metrics endpoint completely.
Example: `:9001`
### `WOODPECKER_ADMIN`
2023-10-24 12:42:05 +00:00
> Default: empty
Comma-separated list of admin accounts.
Example: `WOODPECKER_ADMIN=user1,user2`
### `WOODPECKER_ORGS`
2023-10-24 12:42:05 +00:00
> Default: empty
Comma-separated list of approved organizations.
Example: `org1,org2`
### `WOODPECKER_REPO_OWNERS`
2023-10-24 12:42:05 +00:00
> Default: empty
Comma-separated list of syncable repo owners. ???
Example: `user1,user2`
### `WOODPECKER_OPEN`
2023-10-24 12:42:05 +00:00
> Default: `false`
Enable to allow user registration.
### `WOODPECKER_AUTHENTICATE_PUBLIC_REPOS`
2023-10-24 12:42:05 +00:00
> Default: `false`
Always use authentication to clone repositories even if they are public. Needed if the forge requires to always authenticate as used by many companies.
### `WOODPECKER_DEFAULT_CANCEL_PREVIOUS_PIPELINE_EVENTS`
2023-10-24 12:42:05 +00:00
> Default: `pull_request, push`
List of event names that will be canceled when a new pipeline for the same context (tag, branch) is created.
### `WOODPECKER_DEFAULT_CLONE_IMAGE`
2023-10-24 12:42:05 +00:00
2023-07-31 03:47:23 +00:00
> Default is defined in [shared/constant/constant.go](https://github.com/woodpecker-ci/woodpecker/blob/main/shared/constant/constant.go)
The default docker image to be used when cloning the repo
### `WOODPECKER_DEFAULT_PIPELINE_TIMEOUT`
2023-10-24 12:42:05 +00:00
> 60 (minutes)
The default time for a repo in minutes before a pipeline gets killed
### `WOODPECKER_MAX_PIPELINE_TIMEOUT`
2023-10-24 12:42:05 +00:00
> 120 (minutes)
The maximum time in minutes you can set in the repo settings before a pipeline gets killed
### `WOODPECKER_SESSION_EXPIRES`
2023-10-24 12:42:05 +00:00
> Default: `72h`
Configures the session expiration time.
Context: when someone does log into Woodpecker, a temporary session token is created.
As long as the session is valid (until it expires or log-out),
a user can log into Woodpecker, without re-authentication.
### `WOODPECKER_ESCALATE`
2023-10-24 12:42:05 +00:00
2023-07-31 03:47:23 +00:00
> Defaults are defined in [shared/constant/constant.go](https://github.com/woodpecker-ci/woodpecker/blob/main/shared/constant/constant.go)
Docker images to run in privileged mode. Only change if you are sure what you do!
<!--
### `WOODPECKER_VOLUME`
> Default: empty
Comma-separated list of Docker volumes that are mounted into every pipeline step.
Example: `WOODPECKER_VOLUME=/path/on/host:/path/in/container:rw`|
-->
### `WOODPECKER_DOCKER_CONFIG`
2023-10-24 12:42:05 +00:00
> Default: empty
Configures a specific private registry config for all pipelines.
Example: `WOODPECKER_DOCKER_CONFIG=/home/user/.docker/config.json`
<!--
### `WOODPECKER_ENVIRONMENT`
> Default: empty
TODO
### `WOODPECKER_NETWORK`
> Default: empty
Comma-separated list of Docker networks that are attached to every pipeline step.
Example: `WOODPECKER_NETWORK=network1,network2`
-->
### `WOODPECKER_AGENT_SECRET`
2023-10-24 12:42:05 +00:00
> Default: empty
A shared secret used by server and agents to authenticate communication. A secret can be generated by `openssl rand -hex 32`.
### `WOODPECKER_AGENT_SECRET_FILE`
2023-10-24 12:42:05 +00:00
> Default: empty
Read the value for `WOODPECKER_AGENT_SECRET` from the specified filepath
### `WOODPECKER_KEEPALIVE_MIN_TIME`
2023-10-24 12:42:05 +00:00
> Default: empty
Server-side enforcement policy on the minimum amount of time a client should wait before sending a keepalive ping.
Example: `WOODPECKER_KEEPALIVE_MIN_TIME=10s`
### `WOODPECKER_DATABASE_DRIVER`
2023-10-24 12:42:05 +00:00
> Default: `sqlite3`
The database driver name. Possible values are `sqlite3`, `mysql` or `postgres`.
### `WOODPECKER_DATABASE_DATASOURCE`
2023-10-24 12:42:05 +00:00
> Default: `woodpecker.sqlite` if not running inside a container, `/var/lib/woodpecker/woodpecker.sqlite` if running inside a container
2022-10-15 19:25:07 +00:00
The database connection string. The default value is the path of the embedded SQLite database file.
Example:
2023-10-24 12:42:05 +00:00
```bash
# MySQL
# https://github.com/go-sql-driver/mysql#dsn-data-source-name
WOODPECKER_DATABASE_DATASOURCE=root:password@tcp(1.2.3.4:3306)/woodpecker?parseTime=true
# PostgreSQL
# https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNSTRING
WOODPECKER_DATABASE_DATASOURCE=postgres://root:password@1.2.3.4:5432/woodpecker?sslmode=disable
```
### `WOODPECKER_DATABASE_DATASOURCE_FILE`
2023-10-24 12:42:05 +00:00
> Default: empty
Read the value for `WOODPECKER_DATABASE_DATASOURCE` from the specified filepath
### `WOODPECKER_PROMETHEUS_AUTH_TOKEN`
2023-10-24 12:42:05 +00:00
> Default: empty
Token to secure the Prometheus metrics endpoint.
Must be set to enable the endpoint.
### `WOODPECKER_PROMETHEUS_AUTH_TOKEN_FILE`
2023-10-24 12:42:05 +00:00
> Default: empty
Read the value for `WOODPECKER_PROMETHEUS_AUTH_TOKEN` from the specified filepath
### `WOODPECKER_STATUS_CONTEXT`
2023-10-24 12:42:05 +00:00
> Default: `ci/woodpecker`
Context prefix Woodpecker will use to publish status messages to SCM. You probably will only need to change it if you run multiple Woodpecker instances for a single repository.
### `WOODPECKER_STATUS_CONTEXT_FORMAT`
2023-10-24 12:42:05 +00:00
> Default: `{{ .context }}/{{ .event }}/{{ .workflow }}{{if not (eq .axis_id 0)}}/{{.axis_id}}{{end}}`
Template for the status messages published to forges, uses [Go templates](https://pkg.go.dev/text/template) as template language.
Supported variables:
- `context`: Woodpecker's context (see `WOODPECKER_STATUS_CONTEXT`)
- `event`: the event which started the pipeline
- `workflow`: the workflow's name
- `owner`: the repo's owner
- `repo`: the repo's name
---
### `WOODPECKER_LIMIT_MEM_SWAP`
2023-10-24 12:42:05 +00:00
> Default: `0`
The maximum amount of memory a single pipeline container is allowed to swap to disk, configured in bytes. There is no limit if `0`.
### `WOODPECKER_LIMIT_MEM`
2023-10-24 12:42:05 +00:00
> Default: `0`
The maximum amount of memory a single pipeline container can use, configured in bytes. There is no limit if `0`.
### `WOODPECKER_LIMIT_SHM_SIZE`
2023-10-24 12:42:05 +00:00
> Default: `0`
The maximum amount of memory of `/dev/shm` allowed in bytes. There is no limit if `0`.
### `WOODPECKER_LIMIT_CPU_QUOTA`
2023-10-24 12:42:05 +00:00
> Default: `0`
The number of microseconds per CPU period that the container is limited to before throttled. There is no limit if `0`.
### `WOODPECKER_LIMIT_CPU_SHARES`
2023-10-24 12:42:05 +00:00
> Default: `0`
The relative weight vs. other containers.
### `WOODPECKER_LIMIT_CPU_SET`
2023-10-24 12:42:05 +00:00
> Default: empty
Comma-separated list to limit the specific CPUs or cores a pipeline container can use.
Example: `WOODPECKER_LIMIT_CPU_SET=1,2`
### `WOODPECKER_CONFIG_SERVICE_ENDPOINT`
2023-10-24 12:42:05 +00:00
> Default: empty
2022-08-31 23:52:52 +00:00
Specify a configuration service endpoint, see [Configuration Extension](./100-external-configuration-api.md)
### `WOODPECKER_FORGE_TIMEOUT`
2023-10-24 12:42:05 +00:00
> Default: 3s
Specify timeout when fetching the Woodpecker configuration from forge. See <https://pkg.go.dev/time#ParseDuration> for syntax reference.
### `WOODPECKER_ENABLE_SWAGGER`
2023-10-24 12:42:05 +00:00
> Default: true
Enable the Swagger UI for API documentation.
### `WOODPECKER_DISABLE_VERSION_CHECK`
> Default: false
Disable version check in admin web UI.
---
### `WOODPECKER_GITHUB_...`
See [GitHub configuration](./11-forges/20-github.md#configuration)
### `WOODPECKER_GITEA_...`
See [Gitea configuration](./11-forges/30-gitea.md#configuration)
### `WOODPECKER_BITBUCKET_...`
See [Bitbucket configuration](./11-forges/50-bitbucket.md#configuration)
### `WOODPECKER_GITLAB_...`
See [GitLab configuration](./11-forges/40-gitlab.md#configuration)
### `WOODPECKER_ADDON_FORGE`
See [addon forges](./11-forges/100-addon.md).