mirrors/woodpecker
1
0
Fork 0
mirror of https://github.com/woodpecker-ci/woodpecker.git synced 2025-01-08 16:45:30 +00:00
Code Issues Projects Releases Wiki Activity

cspell lint docs (#3787)

Browse source 
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
This commit is contained in:
6543 2024-07-22 20:42:00 +02:00 committed by GitHub
parent 251129a29c
commit c8411d7f83
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
41 changed files with 177 additions and 100 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

70
.cspell.json
View file

@ -6,27 +6,31 @@
"en_us",
// code
"go",
"node",
// package names
"npm"
"node"
],
"words": [
"abool",
"anbraten",
"antfu",
"apimachinery",
"Archlinux",
"autoincr",
"autoscaler",
"backporting",
"backports",
"binutils",
"bitbucketdatacenter",
"Boguslawski",
"bradrydzewski",
"BUILDPLATFORM",
"buildx",
"caddyfile",
"ccmenu",
"certmagic",
"charmbracelet",
"cicd",
"ciphertext",
"Cloudron",
"Codeberg",
"compatiblelicenses",
"corepack",
@ -38,6 +42,8 @@
"Debugf",
"desaturate",
"devx",
"dind",
"Dockle",
"doublestar",
"envsubst",
"errgroup",
@ -46,16 +52,21 @@
"excalidraw",
"favicons",
"Fediverse",
"Feishu",
"Fogas",
"forbidigo",
"Forgejo",
"fsnotify",
"Geeklab",
"Georgiana",
"gitea",
"gitmodules",
"GOARCH",
"GOBIN",
"gocritic",
"GODEBUG",
"godoc",
"Gogs",
"golangci",
"gomod",
"gonic",
@ -63,6 +74,8 @@
"HEALTHCHECK",
"healthz",
"Hetzner",
"HETZNERCLOUD",
"homelab",
"HTMLURL",
"HTTPFS",
"httpsig",
@ -70,40 +83,56 @@
"httputil",
"ianvs",
"iconify",
"inetutils",
"Infima",
"Infof",
"Informatyka",
"intlify",
"Ionescu",
"Jetpack",
"Kaniko",
"Keyfunc",
"kyvg",
"LASTEXITCODE",
"Laszlo",
"laszlocph",
"letsencrypt",
"loadbalancer",
"logfile",
"loglevel",
"LONGBLOB",
"LONGTEXT",
"lonix1",
"mapstructure",
"markdownlint",
"mdbook",
"memswap",
"Metas",
"mhmxs",
"moby",
"Msgf",
"mstruebing",
"multiarch",
"multierr",
"netdns",
"Netrc",
"Nextcloud",
"nfpm",
"nixos",
"nixpkgs",
"nocolor",
"nolint",
"norunningpipelines",
"nosniff",
"ntfy",
"octocat",
"opensource",
"Pacman",
"picus",
"Pinia",
"pkce",
"pnpx",
"Polyform",
"posix",
"ppid",
"Println",
@ -123,6 +152,7 @@
"repology",
"reslimit",
"Reviewdog",
"Rieter",
"riscv",
"rundll32",
"Rydzewski",
@ -131,11 +161,15 @@
"securecookie",
"sess",
"shellescape",
"Sonatype",
"SSHURL",
"sslmode",
"stepbuilder",
"stretchr",
"structs",
"sublicensable",
"swaggo",
"syscalls",
"TARGETARCH",
"TARGETOS",
"techknowlogick",
@ -143,38 +177,47 @@
"threadcreate",
"tink",
"tinycolor",
"tmole",
"tmpfs",
"tmpl",
"tolerations",
"Traefik",
"tseslint",
"ttlcache",
"Tunnelmole",
"typecheck",
"Typeflag",
"unplugin",
"Upsert",
"urfave",
"usecase",
"varchar",
"varz",
"Vieter",
"virtualisation",
"vite",
"vueuse",
"waivable",
"Warnf",
"webhookd",
"Weblate",
"windi",
"windicss",
"woodpeckerci",
"WORKDIR",
"Wrapf",
"x-enum-varnames",
"xlink",
"xlog",
"xorm",
"xormigrate",
"xyaml",
"yamls",
"Yuno",
"zerolog",
"zerologger"
],
"ignorePaths": [
"**/node_modules/**/*",
"*.excalidraw",
"*.svg",
"*_test.go",
@ -185,19 +228,26 @@
".vscode/extensions.json",
"CHANGELOG.md",
"Makefile",
"flake.lock",
"flake.nix",
"go.mod",
"go.sum",
"pipeline/rpc/proto/woodpecker.pb.go",
"pnpm-lock.yaml",
"server/store/datastore/migration/**/*",
"web/components.d.ts",
"web/src/assets/locales/**/*",
"**/fixtures/**",
"**/testdata/**",
"docs/versioned_docs/",
"package.json",
"91-migrations.md",
// generated
"go.sum",
"flake.lock",
"pnpm-lock.yaml",
"**/node_modules/**/*",
"cmd/server/docs/docs.go",
// TODO: remove the following
"docs/"
"docs/**/*.js",
"docs/**/*.ts"
],
// Exclude imports, because they are also strings.
"ignoreRegExpList": [
@ -210,7 +260,9 @@
// ignore nolint directive
"//\\s*nolint:.*",
// ignore docker image names
"\\s*docker\\.io/.*"
"\\s*docker\\.io/.*",
// ignore inline svg in css
"\\s*url\\(\"data:image/svg\\+xml.*"
],
"enableFiletypes": ["dockercompose"]
}

2
docs/blog/2024-05-27-release-v2.5.0/index.md
View file

@ -45,7 +45,7 @@ NUMBER STATUS EVENT BRANCH COMMIT AUTHO
42 success push
```
In addition especially useful for programmtic usage there is a `go-template` output format which will output the data using the provided go template like this:
In addition especially useful for programmatic usage there is a `go-template` output format which will output the data using the provided go template like this:
```bash
########

2
docs/docs/10-intro/index.md
View file

@ -17,7 +17,7 @@ checks, tests and routines along the way. A typical pipeline might include the f
If you are already using containers in your daily workflow, you'll for sure love Woodpecker. If not yet, you'll be amazed how easy it is to get started with [containers](https://opencontainers.org/).
## Already have access to a Woodpecker instace?
## Already have access to a Woodpecker instance?
Then you might want to jump directly into it and [start creating your first pipelines](../20-usage/10-intro.md).

2
docs/docs/20-usage/10-intro.md
View file

@ -61,7 +61,7 @@ You can use any image from registries like the [Docker Hub](https://hub.docker.c
steps:
- name: build
- image: debian
+ image: mycompany/image-with-awscli
+ image: my-company/image-with-aws_cli
commands:
- aws help
```

4
docs/docs/20-usage/20-workflow-syntax.md
View file

@ -201,7 +201,7 @@ Some of the steps may be allowed to fail without causing the whole workflow and
### `when` - Conditional Execution
Woodpecker supports defining a list of conditions for a step by using a `when` block. If at least one of the conditions in the `when` block evaluate to true the step is executed, otherwise it is skipped. A condition is evaluated to true if _all_ subconditions are true.
Woodpecker supports defining a list of conditions for a step by using a `when` block. If at least one of the conditions in the `when` block evaluate to true the step is executed, otherwise it is skipped. A condition is evaluated to true if _all_ sub-conditions are true.
A condition can be a check like:
```diff
@ -220,7 +220,7 @@ A condition can be a check like:
The `slack` step is executed if one of these conditions is met:
1. The pipeline is executed from a pull request in the repo `test/test`
2. The pipeline is executed from a push to `maiǹ`
2. The pipeline is executed from a push to `main`
#### `repo`

2
docs/docs/20-usage/40-secrets.md
View file

@ -105,7 +105,7 @@ Create the secrets and limit to a set of images:
woodpecker-cli secret add \
-repository octocat/hello-world \
+ -image plugins/s3 \
+ -image peloton/woodpecker-ecs \
+ -image woodpeckerci/plugin-ecs \
-name aws_access_key_id \
-value <value>
```

4
docs/docs/20-usage/41-registries.md
View file

@ -32,8 +32,8 @@ Example registry hostname matching logic:
- Hostname `gcr.io` matches image `gcr.io/foo/bar`
- Hostname `docker.io` matches `golang`
- Hostname `docker.io` matches `library/golang`
- Hostname `docker.io` matches `bradyrydzewski/golang`
- Hostname `docker.io` matches `bradyrydzewski/golang:latest`
- Hostname `docker.io` matches `bradrydzewski/golang`
- Hostname `docker.io` matches `bradrydzewski/golang:latest`
:::note
The flow above doesn't work in Kubernetes. There is [workaround](../30-administration/22-backends/40-kubernetes.md#images-from-private-registries).

2
docs/docs/20-usage/51-plugins/20-creating-plugins.md
View file

@ -10,7 +10,7 @@ These are passed to your plugin as uppercase env vars with a `PLUGIN_` prefix.
Using a setting like `url` results in an env var named `PLUGIN_URL`.
Characters like `-` are converted to an underscore (`_`). `some_String` gets `PLUGIN_SOME_STRING`.
CamelCase is not respected, `anInt` get `PLUGIN_ANINT`.
CamelCase is not respected, `anInt` get `PLUGIN_ANINT`. <!-- cspell:ignore ANINT -->
### Basic settings

11
docs/docs/20-usage/51-plugins/51-overview.md
View file

@ -1,11 +1,12 @@
# Plugins
Plugins are pipeline steps that perform pre-defined tasks and are configured as steps in your pipeline. Plugins can be used to deploy code, publish artifacts, send notification, and more.
Plugins are pipeline steps that perform pre-defined tasks and are configured as steps in your pipeline.
Plugins can be used to deploy code, publish artifacts, send notification, and more.
They are automatically pulled from the default container registry the agent's have configured.
```dockerfile title="Dockerfile"
FROM laszlocloud/kubectl
FROM cloud/kubectl
COPY deploy /usr/local/deploy
ENTRYPOINT ["/usr/local/deploy"]
```
@ -17,7 +18,7 @@ kubectl apply -f $PLUGIN_TEMPLATE
```yaml title=".woodpecker.yaml"
steps:
- name: deploy-to-k8s
image: laszlocloud/my-k8s-plugin
image: cloud/my-k8s-plugin
settings:
template: config/k8s/service.yaml
```
@ -49,9 +50,9 @@ steps:
Plugins are just pipeline steps. They share the build workspace, mounted as a volume, and therefore have access to your source tree.
While normal steps are all about arbitrary code execution, plugins should only allow the functions intended by the plugin author.
So there are a few limitations, like the workspace base is always mounted at `/woodpecker`, but the working directory is dynamically adjusted acordingly. So as user of a plugin you should not have to care about this.
So there are a few limitations, like the workspace base is always mounted at `/woodpecker`, but the working directory is dynamically adjusted accordingly. So as user of a plugin you should not have to care about this.
Also instead of using environment variables the plugin should only care about one prefixed with `PLUGIN_` witch are the internaml representation of the **settings** ([read more](./20-creating-plugins.md)).
Also instead of using environment variables the plugin should only care about one prefixed with `PLUGIN_` witch are the internal representation of the **settings** ([read more](./20-creating-plugins.md)).
## Finding Plugins

2
docs/docs/20-usage/60-services.md
View file

@ -110,5 +110,5 @@ steps:
commands:
- ( apt update && apt dist-upgrade -y && apt install -y mysql-client 2>&1 )> /dev/null
- sleep 30s # need to wait for mysql-server init
- echo 'SHOW VARIABLES LIKE "version"' | mysql -uroot -hdatabase test -pexample
- echo 'SHOW VARIABLES LIKE "version"' | mysql -u root -h database test -p example
```

2
docs/docs/20-usage/90-advanced-usage.md
View file

@ -97,7 +97,7 @@ steps:
### References
- [Official YAML specification](https://yaml.org/spec/1.2.2/#3222-anchors-and-aliases)
- [YAML Cheatsheet](https://learnxinyminutes.com/docs/yaml)
- [YAML cheat sheet](https://learnxinyminutes.com/docs/yaml)
## Persisting environment data between steps

4
docs/docs/30-administration/00-getting-started.md
View file

@ -1,4 +1,4 @@
# Gettings started
# Getting started
A Woodpecker deployment consists of two parts:
@ -45,7 +45,7 @@ By default Woodpecker uses a SQLite database which requires zero installation or
## Forge
What would be a CI/CD system without any code? By connecting Woodpecker to your [forge](../20-usage/15-terminology/index.md) like GitHub or Gitea you can start running pipelines on events like pushes or pull requests. Woodpecker will also use your forge for authentication and to report back the status of your pipelines. See the [forge settings](./11-forges/11-overview.md) to conntect it to Woodpecker.
What would be a CI/CD system without any code? By connecting Woodpecker to your [forge](../20-usage/15-terminology/index.md) like GitHub or Gitea you can start running pipelines on events like pushes or pull requests. Woodpecker will also use your forge for authentication and to report back the status of your pipelines. See the [forge settings](./11-forges/11-overview.md) to connect it to Woodpecker.
## Configuration

2
docs/docs/30-administration/05-deployment-methods/20-kubernetes.md
View file

@ -3,7 +3,7 @@
We recommended to deploy Woodpecker using the [Woodpecker helm chart](https://github.com/woodpecker-ci/helm).
Have a look at the [`values.yaml`](https://github.com/woodpecker-ci/helm/blob/main/charts/woodpecker/values.yaml) config files for all available settings.
The chart contains two subcharts, `server` and `agent` which are automatically configured as needed.
The chart contains two sub-charts, `server` and `agent` which are automatically configured as needed.
The chart started off with two independent charts but was merged into one to simplify the deployment at start of 2023.
A couple of backend-specific config env vars exists which are described in the [kubernetes backend docs](../22-backends/40-kubernetes.md).

2
docs/docs/30-administration/05-deployment-methods/40-nixos.md
View file

@ -10,6 +10,8 @@ In practice, the settings are specified declaratively in the NixOS configuration
## General Configuration
<!-- cspell:words Optimisation -->
```nix
{ config
, ...

12
docs/docs/30-administration/10-server-config.md
View file

@ -26,14 +26,14 @@ You can **also restrict** registration, by keep registration closed and:
```ini
WOODPECKER_OPEN=false
WOODPECKER_ADMIN=johnsmith,janedoe
WOODPECKER_ADMIN=john.smith,jane_doe
```
### Only allow registration of users, who are members of approved organizations
```ini
WOODPECKER_OPEN=true
WOODPECKER_ORGS=dolores,dogpatch
WOODPECKER_ORGS=dolores,dog-patch
```
## Administrators
@ -41,7 +41,7 @@ WOODPECKER_ORGS=dolores,dogpatch
Administrators should also be enumerated in your configuration.
```ini
WOODPECKER_ADMIN=johnsmith,janedoe
WOODPECKER_ADMIN=john.smith,jane_doe
```
## Filtering repositories
@ -51,7 +51,7 @@ Woodpecker operates with the user's OAuth permission. Due to the coarse permissi
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
WOODPECKER_REPO_OWNERS=my_company,my_company_oss_github_user
```
## Global registry setting
@ -133,7 +133,7 @@ The examples below show how to place a banner message in the top navigation bar
### `woodpecker.js`
```javascript
// place/copy a minified version of jQuery or ZeptoJS here ...
// place/copy a minified version of your preferred lightweight JavaScript library here ...
!(function () {
'use strict';
function e() {} /*...*/
@ -305,7 +305,7 @@ Example: `org1,org2`
> Default: empty
Comma-separated list of syncable repo owners. ???
Repositories by those owners will be allowed to be used in woodpecker.
Example: `user1,user2`

5
docs/docs/30-administration/11-forges/60-bitbucket_datacenter.md
View file

@ -35,7 +35,10 @@ Woodpecker uses `git+https` to clone repositories, however, Bitbucket Server doe
## Registration
Woodpecker must be registered with Bitbucket Datacenter / Server. In the administration section of Bitbucket choose "Application Links" and then "Create link". Woodpecker should be listed as "External Application" and the direction should be set to "Incomming". Note the client id and client secret of the registration to be used in the configuration of Woodpecker.
Woodpecker must be registered with Bitbucket Datacenter / Server.
In the administration section of Bitbucket choose "Application Links" and then "Create link".
Woodpecker should be listed as "External Application" and the direction should be set to "Incoming".
Note the client id and client secret of the registration to be used in the configuration of Woodpecker.
See also [Configure an incoming link](https://confluence.atlassian.com/bitbucketserver/configure-an-incoming-link-1108483657.html).

2
docs/docs/30-administration/22-backends/10-docker.md
View file

@ -32,6 +32,8 @@ The following commands **are destructive** and **irreversible** it is highly rec
### Remove all unused images
<!-- cspell:ignore trunc -->
```bash
docker image rm $(docker images --filter "dangling=true" -q --no-trunc)
```

13
docs/docs/30-administration/22-backends/40-kubernetes.md
View file

@ -107,7 +107,7 @@ steps:
limits:
memory: 256Mi
nodeSelector:
beta.kubernetes.io/instance-type: p3.8xlarge
beta.kubernetes.io/instance-type: Standard_D2_v3
tolerations:
- key: 'key1'
operator: 'Equal'
@ -156,6 +156,8 @@ Note that the `backend_options.kubernetes.securityContext` object allows you to
By default, the properties will be set at the Pod level. Properties that are only supported on the container level will be set there instead. So, the
configuration shown above will result in something like the following Pod spec:
<!-- cspell:disable -->
```yaml
kind: Pod
spec:
@ -170,7 +172,9 @@ spec:
[...]
```
You can also restrict a container's syscalls with [seccomp](https://kubernetes.io/docs/tutorials/security/seccomp/) profile
<!-- cspell:enable -->
You can also restrict a syscalls of containers with [seccomp](https://kubernetes.io/docs/tutorials/security/seccomp/) profile.
```yaml
backend_options:
@ -230,7 +234,8 @@ See [this issue](https://github.com/woodpecker-ci/woodpecker/issues/2510) for mo
### `KUBERNETES_SERVICE_HOST` environment variable
Like the below env vars used for configuration, this can be set in the environment fonfiguration of the agent. It configures the address of the Kubernetes API server to connect to.
Like the below env vars used for configuration, this can be set in the environment for configuration of the agent.
It configures the address of the Kubernetes API server to connect to.
If running the agent within Kubernetes, this will already be set and you don't have to add it manually.
@ -292,7 +297,7 @@ Determines if Pod annotations can be defined from a step's backend options.
Additional node selector to apply to worker pods. Must be a YAML object, e.g. `{"topology.kubernetes.io/region":"eu-central-1"}`.
### `WOODPECKER_BACKEND_K8S_SECCTX_NONROOT`
### `WOODPECKER_BACKEND_K8S_SECCTX_NONROOT` <!-- cspell:ignore SECCTX NONROOT -->
> Default: `false`

2
docs/docs/30-administration/22-backends/50-custom-backends.md
View file

@ -1,6 +1,6 @@
# Custom backends
If none of our backends fits your usecases, you can write your own.
If none of our backends fits your usecase, you can write your own.
Therefore, implement the interface `"go.woodpecker-ci.org/woodpecker/woodpecker/v2/pipeline/backend/types".Backend` and
build a custom agent using your backend with this `main.go`:

18
docs/docs/30-administration/40-advanced/10-proxy.md
View file

@ -4,6 +4,8 @@
This guide provides a brief overview for installing Woodpecker server behind the Apache2 web-server. This is an example configuration:
<!-- cspell:ignore apacheconf -->
```apacheconf
ProxyPreserveHost On
@ -87,7 +89,7 @@ woodpecker.example.com {
}
# expose gRPC
woodpeckeragent.example.com {
woodpecker-agent.example.com {
reverse_proxy h2c://woodpecker-server:9000
}
```
@ -132,6 +134,8 @@ Set `WOODPECKER_HOST` to the ngrok URL (usually xxx.ngrok.io) and start the serv
To install the Woodpecker server behind a [Traefik](https://traefik.io/) load balancer, you must expose both the `http` and the `gRPC` ports. Here is a comprehensive example, considering you are running Traefik with docker swarm and want to do TLS termination and automatic redirection from http to https.
<!-- cspell:words redirectscheme certresolver -->
```yaml
version: '3.8'
@ -155,13 +159,13 @@ services:
# web server
- traefik.http.services.woodpecker-service.loadbalancer.server.port=8000
- traefik.http.routers.woodpecker-secure.rule=Host(`cd.yourdomain.com`)
- traefik.http.routers.woodpecker-secure.rule=Host(`cd.your-domain.com`)
- traefik.http.routers.woodpecker-secure.tls=true
- traefik.http.routers.woodpecker-secure.tls.certresolver=letsencrypt
- traefik.http.routers.woodpecker-secure.entrypoints=websecure
- traefik.http.routers.woodpecker-secure.entrypoints=web-secure
- traefik.http.routers.woodpecker-secure.service=woodpecker-service
- traefik.http.routers.woodpecker.rule=Host(`cd.yourdomain.com`)
- traefik.http.routers.woodpecker.rule=Host(`cd.your-domain.com`)
- traefik.http.routers.woodpecker.entrypoints=web
- traefik.http.routers.woodpecker.service=woodpecker-service
@ -173,13 +177,13 @@ services:
- traefik.http.services.woodpecker-grpc.loadbalancer.server.port=9000
- traefik.http.services.woodpecker-grpc.loadbalancer.server.scheme=h2c
- traefik.http.routers.woodpecker-grpc-secure.rule=Host(`woodpecker-grpc.yourdomain.com`)
- traefik.http.routers.woodpecker-grpc-secure.rule=Host(`woodpecker-grpc.your-domain.com`)
- traefik.http.routers.woodpecker-grpc-secure.tls=true
- traefik.http.routers.woodpecker-grpc-secure.tls.certresolver=letsencrypt
- traefik.http.routers.woodpecker-grpc-secure.entrypoints=websecure
- traefik.http.routers.woodpecker-grpc-secure.entrypoints=web-secure
- traefik.http.routers.woodpecker-grpc-secure.service=woodpecker-grpc
- traefik.http.routers.woodpecker-grpc.rule=Host(`woodpecker-grpc.yourdomain.com`)
- traefik.http.routers.woodpecker-grpc.rule=Host(`woodpecker-grpc.your-domain.com`)
- traefik.http.routers.woodpecker-grpc.entrypoints=web
- traefik.http.routers.woodpecker-grpc.service=woodpecker-grpc

4
docs/docs/30-administration/40-advanced/100-external-configuration-api.md
View file

@ -26,7 +26,7 @@ WOODPECKER_CONFIG_SERVICE_ENDPOINT=https://example.com/ciconfig
"uid": "",
"user_id": 0,
"namespace": "",
"name": "woodpecker-testpipe",
"name": "woodpecker-test-pipe",
"slug": "",
"scm": "git",
"git_http_url": "",
@ -54,7 +54,7 @@ WOODPECKER_CONFIG_SERVICE_ENDPOINT=https://example.com/ciconfig
"author_avatar": "https://myforge.com/avatars/d6b3f7787a685fcdf2a44e2c685c7e03",
"author_email": "my@email.com",
"branch": "main",
"changed_files": ["somefilename.txt"],
"changed_files": ["some-file-name.txt"],
"commit": "2fff90f8d288a4640e90f05049fe30e61a14fd50",
"created_at": 0,
"deploy_to": "",

4
docs/docs/30-administration/40-advanced/30-autoscaler.md
View file

@ -29,8 +29,8 @@ services:
- WOODPECKER_MIN_AGENTS=0
- WOODPECKER_MAX_AGENTS=3
- WOODPECKER_WORKFLOWS_PER_AGENT=2 # the number of workflows each agent can run at the same time
- WOODEPCKER_GRPC_ADDR=https://grpc.your-woodpecker-server.tld # the grpc address of your woodpecker server, publicly accessible from the agents
- WOODEPCKER_GRPC_SECURE=true
- WOODPECKER_GRPC_ADDR=https://grpc.your-woodpecker-server.tld # the grpc address of your woodpecker server, publicly accessible from the agents
- WOODPECKER_GRPC_SECURE=true
- WOODPECKER_AGENT_ENV= # optional environment variables to pass to the agents
- WOODPECKER_PROVIDER=hetznercloud # set the provider, you can find all the available ones down below
- WOODPECKER_HETZNERCLOUD_API_TOKEN=${WOODPECKER_HETZNERCLOUD_API_TOKEN} # your api token for the Hetzner cloud

2
docs/docs/30-administration/40-advanced/40-advanced.md
View file

@ -1,4 +1,4 @@
# Adavanced options
# Advanced options
Why should we be happy with a default setup? We should not! Woodpecker offers a lot of advanced options to configure it to your needs.

4
docs/docs/30-administration/40-advanced/90-prometheus.md
View file

@ -52,11 +52,11 @@ List of Prometheus metrics specific to Woodpecker:
# HELP woodpecker_pipeline_count Pipeline count.
# TYPE woodpecker_pipeline_count counter
woodpecker_pipeline_count{branch="main",pipeline="total",repo="woodpecker-ci/woodpecker",status="success"} 3
woodpecker_pipeline_count{branch="mkdocs",pipeline="total",repo="woodpecker-ci/woodpecker",status="success"} 3
woodpecker_pipeline_count{branch="dev",pipeline="total",repo="woodpecker-ci/woodpecker",status="success"} 3
# HELP woodpecker_pipeline_time Build time.
# TYPE woodpecker_pipeline_time gauge
woodpecker_pipeline_time{branch="main",pipeline="total",repo="woodpecker-ci/woodpecker",status="success"} 116
woodpecker_pipeline_time{branch="mkdocs",pipeline="total",repo="woodpecker-ci/woodpecker",status="success"} 155
woodpecker_pipeline_time{branch="dev",pipeline="total",repo="woodpecker-ci/woodpecker",status="success"} 155
# HELP woodpecker_pipeline_total_count Total number of builds.
# TYPE woodpecker_pipeline_total_count gauge
woodpecker_pipeline_total_count 1025

8
docs/docs/92-development/01-getting-started.md
View file

@ -4,12 +4,12 @@ You can develop on your local computer by following the [steps below](#preparati
## Gitpod
If you want to start development or updating docs as easy as possible, you can use our preconfigured setup for Woodpecker using [Gitpod](https://github.com/gitpod-io/gitpod). Gitpod starts a complete development setup in the cloud containing:
If you want to start development or updating docs as easy as possible, you can use our pre-configured setup for Woodpecker using [Gitpod](https://github.com/gitpod-io/gitpod). Gitpod starts a complete development setup in the cloud containing:
- An IDE in the browser or bridged to your local VS-Code or Jetbrains
- A preconfigured [Gitea](https://github.com/go-gitea/gitea) instance as forge
- A preconfigured Woodpecker server
- A single preconfigured Woodpecker agent node
- A pre-configured [Gitea](https://github.com/go-gitea/gitea) instance as forge
- A pre-configured Woodpecker server
- A single pre-configured Woodpecker agent node
- Our docs preview server
Start Woodpecker in Gitpod by clicking on the following badge. You can log in with `woodpecker` and `password`.

34
docs/docs/92-development/05-architecture.md
View file

@ -19,23 +19,23 @@
### Server
| package | meaning | imports |
| -------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `server/api/**` | handle web requests from `server/router` | `pipeline`, `../badges`, `../ccmenue`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../shared`, `../store`, `shared`, (TODO: mv `server/router/middleware/session`) |
| `server/badges/**` | generate svg badges for pipelines | `../model` |
| `server/ccmenu/**` | generate xml ccmenu for pipelines | `../model` |
| `server/grpc/**` | gRPC server agents can connect to | `pipeline/rpc/**`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../pipeline`, `../store` |
| `server/logging/**` | logging lib for gPRC server to stream logs while running | std |
| `server/model/**` | structs for store (db) and api (json) | std |
| `server/plugins/**` | plugins for server | `../model`, `../forge` |
| `server/pipeline/**` | orchestrate pipelines | `pipeline`, `../model`, `../pubsub`, `../queue`, `../forge`, `../store`, `../plugins` |
| `server/pubsub/**` | pubsub lib for server to push changes to the WebUI | std |
| `server/queue/**` | queue lib for server where agents pull new pipelines from via gRPC | `server/model` |
| `server/forge/**` | forge lib for server to connect and handle forge specific stuff | `shared`, `server/model` |
| `server/router/**` | handle requests to REST API (and all middleware) and serve UI and WebUI config | `shared`, `../api`, `../model`, `../forge`, `../store`, `../web` |
| `server/store/**` | handle database | `server/model` |
| `server/shared/**` | TODO: move and split [#974](https://github.com/woodpecker-ci/woodpecker/issues/974) | |
| `server/web/**` | server SPA | |
| package | meaning | imports |
| -------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `server/api/**` | handle web requests from `server/router` | `pipeline`, `../badges`, `../ccmenu`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../shared`, `../store`, `shared`, (TODO: mv `server/router/middleware/session`) |
| `server/badges/**` | generate svg badges for pipelines | `../model` |
| `server/ccmenu/**` | generate xml ccmenu for pipelines | `../model` |
| `server/grpc/**` | gRPC server agents can connect to | `pipeline/rpc/**`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../pipeline`, `../store` |
| `server/logging/**` | logging lib for gPRC server to stream logs while running | std |
| `server/model/**` | structs for store (db) and api (json) | std |
| `server/plugins/**` | plugins for server | `../model`, `../forge` |
| `server/pipeline/**` | orchestrate pipelines | `pipeline`, `../model`, `../pubsub`, `../queue`, `../forge`, `../store`, `../plugins` |
| `server/pubsub/**` | pubsub lib for server to push changes to the WebUI | std |
| `server/queue/**` | queue lib for server where agents pull new pipelines from via gRPC | `server/model` |
| `server/forge/**` | forge lib for server to connect and handle forge specific stuff | `shared`, `server/model` |
| `server/router/**` | handle requests to REST API (and all middleware) and serve UI and WebUI config | `shared`, `../api`, `../model`, `../forge`, `../store`, `../web` |
| `server/store/**` | handle database | `server/model` |
| `server/shared/**` | TODO: move and split [#974](https://github.com/woodpecker-ci/woodpecker/issues/974) | |
| `server/web/**` | server SPA | |
- `../` = `server/`

6
docs/docs/92-development/09-swagger.md
View file

@ -7,7 +7,7 @@ and then being using on the community's website documentation.
It's paramount important to keep the gin handler function's godoc documentation up-to-date,
to always have accurate API documentation.
Whenever you change, add or enhance an API endpoint, please update the godocs.
Whenever you change, add or enhance an API endpoint, please update the godoc.
You don't require any extra tools on your machine, all Swagger tooling is automatically fetched by standard Go tools.
@ -41,8 +41,8 @@ These guidelines aim to have consistent wording in the swagger doc:
- first word after `@Summary` and `@Summary` are always uppercase
- `@Summary` has no `.` (dot) at the end of the line
- model structs shall use custom short names, to ease life for API consumers, using `@name`
- `@Success` object or array declarations shall be short, this means the actual `model.User` struct must have a `@name` annotation, so that the model can be renderend in Swagger
- when pagination is used, `@Parame page` and `@Parame perPage` must be added manually
- `@Success` object or array declarations shall be short, this means the actual `model.User` struct must have a `@name` annotation, so that the model can be rendered in Swagger
- when pagination is used, `@Param page` and `@Param perPage` must be added manually
- `@Param Authorization` is almost always present, there are just a few un-protected endpoints
There are many examples in the `server/api` package, which you can use a blueprint.

8
docs/docs/92-development/09-testing.md
View file

@ -30,11 +30,13 @@ steps:
services:
echo:
image: dummy
commands: echo "i am a sevice"
commands: echo "i am a service"
```
This could be executed via `woodpecker-cli --log-level trace exec --backend-engine dummy example.yaml`:
<!-- cspell:disable -->
```none
9:18PM DBG pipeline/pipeline.go:94 > executing 2 stages, in order of: CLI=exec
9:18PM DBG pipeline/pipeline.go:104 > stage CLI=exec StagePos=0 Steps=echo
@ -69,7 +71,9 @@ This could be executed via `woodpecker-cli --log-level trace exec --backend-engi
9:18PM TRC pipeline/backend/dummy/dummy.go:208 > delete workflow environment taskUUID=01J10P578JQE6E25VV1EQF0745
```
There are also environment variables to alter step behaviour:
<!-- cspell:enable -->
There are also environment variables to alter step behavior:
- `SLEEP: 10` will let the step wait 10 seconds
- `EXPECT_TYPE` allows to check if a step is a `clone`, `service`, `plugin` or `commands`

2
docs/versioned_docs/version-2.7/10-intro/index.md
View file

@ -17,7 +17,7 @@ checks, tests and routines along the way. A typical pipeline might include the f
If you are already using containers in your daily workflow, you'll for sure love Woodpecker. If not yet, you'll be amazed how easy it is to get started with [containers](https://opencontainers.org/).
## Already have access to a Woodpecker instace?
## Already have access to a Woodpecker instance?
Then you might want to jump directly into it and [start creating your first pipelines](../20-usage/10-intro.md).

2
docs/versioned_docs/version-2.7/20-usage/20-workflow-syntax.md
View file

@ -220,7 +220,7 @@ A condition can be a check like:
The `slack` step is executed if one of these conditions is met:
1. The pipeline is executed from a pull request in the repo `test/test`
2. The pipeline is executed from a push to `maiǹ`
2. The pipeline is executed from a push to `main`
#### `repo`

4
docs/versioned_docs/version-2.7/20-usage/51-plugins/51-overview.md
View file

@ -49,9 +49,9 @@ steps:
Plugins are just pipeline steps. They share the build workspace, mounted as a volume, and therefore have access to your source tree.
While normal steps are all about arbitrary code execution, plugins should only allow the functions intended by the plugin author.
So there are a few limitations, like the workspace base is always mounted at `/woodpecker`, but the working directory is dynamically adjusted acordingly. So as user of a plugin you should not have to care about this.
So there are a few limitations, like the workspace base is always mounted at `/woodpecker`, but the working directory is dynamically adjusted accordingly. So as user of a plugin you should not have to care about this.
Also instead of using environment variables the plugin should only care about one prefixed with `PLUGIN_` witch are the internaml representation of the **settings** ([read more](./20-creating-plugins.md)).
Also instead of using environment variables the plugin should only care about one prefixed with `PLUGIN_` witch are the internal representation of the **settings** ([read more](./20-creating-plugins.md)).
## Finding Plugins

4
docs/versioned_docs/version-2.7/30-administration/00-getting-started.md
View file

@ -1,4 +1,4 @@
# Gettings started
# Getting started
A Woodpecker deployment consists of two parts:
@ -45,7 +45,7 @@ By default Woodpecker uses a SQLite database which requires zero installation or
## Forge
What would be a CI/CD system without any code? By connecting Woodpecker to your [forge](../20-usage/15-terminology/index.md) like GitHub or Gitea you can start running pipelines on events like pushes or pull requests. Woodpecker will also use your forge for authentication and to report back the status of your pipelines. See the [forge settings](./11-forges/11-overview.md) to conntect it to Woodpecker.
What would be a CI/CD system without any code? By connecting Woodpecker to your [forge](../20-usage/15-terminology/index.md) like GitHub or Gitea you can start running pipelines on events like pushes or pull requests. Woodpecker will also use your forge for authentication and to report back the status of your pipelines. See the [forge settings](./11-forges/11-overview.md) to connect it to Woodpecker.
## Configuration

2
docs/versioned_docs/version-2.7/30-administration/10-server-config.md
View file

@ -305,7 +305,7 @@ Example: `org1,org2`
> Default: empty
Comma-separated list of syncable repo owners. ???
Repositories by those owners will be allowed to be used in woodpecker.
Example: `user1,user2`

5
docs/versioned_docs/version-2.7/30-administration/11-forges/60-bitbucket_datacenter.md
View file

@ -35,7 +35,10 @@ Woodpecker uses `git+https` to clone repositories, however, Bitbucket Server doe
## Registration
Woodpecker must be registered with Bitbucket Datacenter / Server. In the administration section of Bitbucket choose "Application Links" and then "Create link". Woodpecker should be listed as "External Application" and the direction should be set to "Incomming". Note the client id and client secret of the registration to be used in the configuration of Woodpecker.
Woodpecker must be registered with Bitbucket Datacenter / Server.
In the administration section of Bitbucket choose "Application Links" and then "Create link".
Woodpecker should be listed as "External Application" and the direction should be set to "Incoming".
Note the client id and client secret of the registration to be used in the configuration of Woodpecker.
See also [Configure an incoming link](https://confluence.atlassian.com/bitbucketserver/configure-an-incoming-link-1108483657.html).

3
docs/versioned_docs/version-2.7/30-administration/22-backends/40-kubernetes.md
View file

@ -230,7 +230,8 @@ See [this issue](https://github.com/woodpecker-ci/woodpecker/issues/2510) for mo
### `KUBERNETES_SERVICE_HOST` environment variable
Like the below env vars used for configuration, this can be set in the environment fonfiguration of the agent. It configures the address of the Kubernetes API server to connect to.
Like the below env vars used for configuration, this can be set in the environment for configuration of the agent.
It configures the address of the Kubernetes API server to connect to.
If running the agent within Kubernetes, this will already be set and you don't have to add it manually.

2
docs/versioned_docs/version-2.7/30-administration/22-backends/50-custom-backends.md
View file

@ -1,6 +1,6 @@
# Custom backends
If none of our backends fits your usecases, you can write your own.
If none of our backends fits your usecase, you can write your own.
Therefore, implement the interface `"go.woodpecker-ci.org/woodpecker/woodpecker/v2/pipeline/backend/types".Backend` and
build a custom agent using your backend with this `main.go`:

4
docs/versioned_docs/version-2.7/30-administration/40-advanced/30-autoscaler.md
View file

@ -29,8 +29,8 @@ services:
- WOODPECKER_MIN_AGENTS=0
- WOODPECKER_MAX_AGENTS=3
- WOODPECKER_WORKFLOWS_PER_AGENT=2 # the number of workflows each agent can run at the same time
- WOODEPCKER_GRPC_ADDR=https://grpc.your-woodpecker-server.tld # the grpc address of your woodpecker server, publicly accessible from the agents
- WOODEPCKER_GRPC_SECURE=true
- WOODPECKER_GRPC_ADDR=https://grpc.your-woodpecker-server.tld # the grpc address of your woodpecker server, publicly accessible from the agents
- WOODPECKER_GRPC_SECURE=true
- WOODPECKER_AGENT_ENV= # optional environment variables to pass to the agents
- WOODPECKER_PROVIDER=hetznercloud # set the provider, you can find all the available ones down below
- WOODPECKER_HETZNERCLOUD_API_TOKEN=${WOODPECKER_HETZNERCLOUD_API_TOKEN} # your api token for the Hetzner cloud

2
docs/versioned_docs/version-2.7/30-administration/40-advanced/40-advanced.md
View file

@ -1,4 +1,4 @@
# Adavanced options
# Advanced options
Why should we be happy with a default setup? We should not! Woodpecker offers a lot of advanced options to configure it to your needs.

4
docs/versioned_docs/version-2.7/92-development/05-architecture.md
View file

@ -21,12 +21,12 @@
| package | meaning | imports |
| -------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `server/api/**` | handle web requests from `server/router` | `pipeline`, `../badges`, `../ccmenue`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../shared`, `../store`, `shared`, (TODO: mv `server/router/middleware/session`) |
| `server/api/**` | handle web requests from `server/router` | `pipeline`, `../badges`, `../ccmenu`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../shared`, `../store`, `shared`, (TODO: mv `server/router/middleware/session`) |
| `server/badges/**` | generate svg badges for pipelines | `../model` |
| `server/ccmenu/**` | generate xml ccmenu for pipelines | `../model` |
| `server/grpc/**` | gRPC server agents can connect to | `pipeline/rpc/**`, `../logging`, `../model`, `../pubsub`, `../queue`, `../forge`, `../pipeline`, `../store` |
| `server/logging/**` | logging lib for gPRC server to stream logs while running | std |
| `server/model/**` | structs for store (db) and api (json) | std |
| `server/model/**` | structs for store (db) and api (json) | std |
| `server/plugins/**` | plugins for server | `../model`, `../forge` |
| `server/pipeline/**` | orchestrate pipelines | `pipeline`, `../model`, `../pubsub`, `../queue`, `../forge`, `../store`, `../plugins` |
| `server/pubsub/**` | pubsub lib for server to push changes to the WebUI | std |

6
docs/versioned_docs/version-2.7/92-development/09-swagger.md
View file

@ -7,7 +7,7 @@ and then being using on the community's website documentation.
It's paramount important to keep the gin handler function's godoc documentation up-to-date,
to always have accurate API documentation.
Whenever you change, add or enhance an API endpoint, please update the godocs.
Whenever you change, add or enhance an API endpoint, please update the godoc.
You don't require any extra tools on your machine, all Swagger tooling is automatically fetched by standard Go tools.
@ -41,8 +41,8 @@ These guidelines aim to have consistent wording in the swagger doc:
- first word after `@Summary` and `@Summary` are always uppercase
- `@Summary` has no `.` (dot) at the end of the line
- model structs shall use custom short names, to ease life for API consumers, using `@name`
- `@Success` object or array declarations shall be short, this means the actual `model.User` struct must have a `@name` annotation, so that the model can be renderend in Swagger
- when pagination is used, `@Parame page` and `@Parame perPage` must be added manually
- `@Success` object or array declarations shall be short, this means the actual `model.User` struct must have a `@name` annotation, so that the model can be rendered in Swagger
- when pagination is used, `@Param page` and `@Param perPage` must be added manually
- `@Param Authorization` is almost always present, there are just a few un-protected endpoints
There are many examples in the `server/api` package, which you can use a blueprint.

4
docs/versioned_docs/version-2.7/92-development/09-testing.md
View file

@ -30,7 +30,7 @@ steps:
services:
echo:
image: dummy
commands: echo "i am a sevice"
commands: echo "i am a service"
```
This could be executed via `woodpecker-cli --log-level trace exec --backend-engine dummy example.yaml`:
@ -69,7 +69,7 @@ This could be executed via `woodpecker-cli --log-level trace exec --backend-engi
9:18PM TRC pipeline/backend/dummy/dummy.go:208 > delete workflow environment taskUUID=01J10P578JQE6E25VV1EQF0745
```
There are also environment variables to alter step behaviour:
There are also environment variables to alter step behavior:
- `SLEEP: 10` will let the step wait 10 seconds
- `EXPECT_TYPE` allows to check if a step is a `clone`, `service`, `plugin` or `commands`