diff --git a/cmd/server/openapi/docs.go b/cmd/server/openapi/docs.go index ba2940d67..59e148fc4 100644 --- a/cmd/server/openapi/docs.go +++ b/cmd/server/openapi/docs.go @@ -2966,6 +2966,24 @@ const docTemplate = `{ "description": "only return pipelines after this RFC3339 date", "name": "after", "in": "query" + }, + { + "type": "string", + "description": "filter pipelines by branch", + "name": "branch", + "in": "query" + }, + { + "type": "string", + "description": "filter pipelines by webhook events (comma separated)", + "name": "event", + "in": "query" + }, + { + "type": "string", + "description": "filter pipelines by strings contained in ref", + "name": "ref", + "in": "query" } ], "responses": { diff --git a/docs/docusaurus.config.ts b/docs/docusaurus.config.ts index 405595ffe..572bcc723 100644 --- a/docs/docusaurus.config.ts +++ b/docs/docusaurus.config.ts @@ -236,25 +236,25 @@ const config: Config = { sidebarPath: require.resolve('./sidebars.js'), editUrl: 'https://github.com/woodpecker-ci/woodpecker/edit/main/docs/', includeCurrentVersion: true, - lastVersion: '2.7', + lastVersion: '2.8', onlyIncludeVersions: - process.env.NODE_ENV === 'development' ? ['current', '2.7'] : ['current', '2.7', '2.6', '2.5', '1.0'], + process.env.NODE_ENV === 'development' ? ['current', '2.8'] : ['current', '2.8', '2.7', '2.6', '1.0'], versions: { current: { label: 'Next 🚧', banner: 'unreleased', }, + '2.8': { + label: '2.8.x', + }, '2.7': { label: '2.7.x', + banner: 'unmaintained', }, '2.6': { label: '2.6.x 💀', banner: 'unmaintained', }, - '2.5': { - label: '2.5.x 💀', - banner: 'unmaintained', - }, '1.0': { label: '1.0.x 💀', banner: 'unmaintained', diff --git a/docs/src/pages/versions.md b/docs/src/pages/versions.md index c74291edc..081f94495 100644 --- a/docs/src/pages/versions.md +++ b/docs/src/pages/versions.md @@ -33,6 +33,7 @@ Here you can find documentation for previous versions of Woodpecker. | | | | | ------- | ---------- | ------------------------------------------------------------------------------------- | +| 2.7.3 | 2024-11-28 | [Documentation](https://github.com/woodpecker-ci/woodpecker/tree/v2.7.3/docs/docs/) | | 2.7.2 | 2024-11-03 | [Documentation](https://github.com/woodpecker-ci/woodpecker/tree/v2.7.2/docs/docs/) | | 2.7.1 | 2024-09-07 | [Documentation](https://github.com/woodpecker-ci/woodpecker/tree/v2.7.1/docs/docs/) | | 2.7.0 | 2024-07-18 | [Documentation](https://github.com/woodpecker-ci/woodpecker/tree/v2.7.0/docs/docs/) | diff --git a/docs/versioned_docs/version-2.5/10-intro.md b/docs/versioned_docs/version-2.5/10-intro.md deleted file mode 100644 index e4624e623..000000000 --- a/docs/versioned_docs/version-2.5/10-intro.md +++ /dev/null @@ -1,89 +0,0 @@ -# Welcome to Woodpecker - -Woodpecker is a simple, yet powerful CI/CD engine with great extensibility. It focuses on executing pipelines inside [containers](https://opencontainers.org/). -If you are already using containers in your daily workflow, you'll for sure love Woodpecker. - -![woodpecker](woodpecker.png) - -## `.woodpecker.yaml` - -- Place your pipeline in a file named `.woodpecker.yaml` in your repository -- Pipeline steps can be named as you like -- Run any command in the commands section - -```yaml title=".woodpecker.yaml" -steps: - - name: build - image: debian - commands: - - echo "This is the build step" - - name: a-test-step - image: debian - commands: - - echo "Testing.." -``` - -### Steps are containers - -- Define any container image as context - - either use your own and install the needed tools in a custom image - - or search for available images that are already tailored for your needs in image registries like [Docker Hub](https://hub.docker.com/search?type=image) -- List the commands that should be executed in the container - -```diff - steps: - - name: build -- image: debian -+ image: mycompany/image-with-awscli - commands: - - aws help -``` - -### File changes are incremental - -- Woodpecker clones the source code in the beginning -- File changes are persisted throughout individual steps as the same volume is being mounted in all steps - -```yaml title=".woodpecker.yaml" -steps: - - name: build - image: debian - commands: - - touch myfile - - name: a-test-step - image: debian - commands: - - cat myfile -``` - -## Plugins are straightforward - -- If you copy the same shell script from project to project -- Pack it into a plugin instead -- And make the yaml declarative -- Plugins are Docker images with your script as an entrypoint - -```dockerfile title="Dockerfile" -FROM laszlocloud/kubectl -COPY deploy /usr/local/deploy -ENTRYPOINT ["/usr/local/deploy"] -``` - -```bash title="deploy" -kubectl apply -f $PLUGIN_TEMPLATE -``` - -```yaml title=".woodpecker.yaml" -steps: - - name: deploy-to-k8s - image: laszlocloud/my-k8s-plugin - settings: - template: config/k8s/service.yaml -``` - -See [plugin docs](./20-usage/51-plugins/51-overview.md). - -## Continue reading - -- [Create a Woodpecker pipeline for your repository](./20-usage/10-intro.md) -- [Setup your own Woodpecker instance](./30-administration/00-deployment/00-overview.md) diff --git a/docs/versioned_docs/version-2.5/20-usage/10-intro.md b/docs/versioned_docs/version-2.5/20-usage/10-intro.md deleted file mode 100644 index 477466173..000000000 --- a/docs/versioned_docs/version-2.5/20-usage/10-intro.md +++ /dev/null @@ -1,72 +0,0 @@ -# Getting started - -## Repository Activation - -To activate your project navigate to your account settings. You will see a list of repositories which can be activated with a simple toggle. When you activate your repository, Woodpecker automatically adds webhooks to your forge (e.g. GitHub, Gitea, ...). - -Webhooks are used to trigger pipeline executions. When you push code to your repository, open a pull request, or create a tag, your forge will automatically send a webhook to Woodpecker which will in turn trigger the pipeline execution. - -![repository list](repo-list.png) - -## Required Permissions - -The user who enables a repo in Woodpecker must have `Admin` rights on that repo, so that Woodpecker can add the webhook. - -:::note -Note that manually creating webhooks yourself is not possible. -This is because webhooks are signed using a per-repository secret key which is not exposed to end users. -::: - -## Configuration - -To configure your pipeline you must create a `.woodpecker.yaml` file in the root of your repository. The `.woodpecker.yaml` file is used to define your pipeline steps. - -:::note -We support most of YAML 1.2, but preserve some behavior from 1.1 for backward compatibility. -Read more at: [https://github.com/go-yaml/yaml](https://github.com/go-yaml/yaml/tree/v3) -::: - -Example pipeline configuration: - -```yaml -steps: - - name: build - image: golang - commands: - - go get - - go build - - go test - -services: - - name: postgres - image: postgres:9.4.5 - environment: - - POSTGRES_USER=myapp -``` - -Example pipeline configuration with multiple, serial steps: - -```yaml -steps: - - name: backend - image: golang - commands: - - go get - - go build - - go test - - - name: frontend - image: node:6 - commands: - - npm install - - npm test - - - name: notify - image: plugins/slack - channel: developers - username: woodpecker -``` - -## Execution - -To trigger your first pipeline execution you can push code to your repository, open a pull request, or push a tag. Any of these events triggers a webhook from your forge and execute your pipeline. diff --git a/docs/versioned_docs/version-2.5/20-usage/project-settings.png b/docs/versioned_docs/version-2.5/20-usage/project-settings.png deleted file mode 100644 index fc29daac8..000000000 Binary files a/docs/versioned_docs/version-2.5/20-usage/project-settings.png and /dev/null differ diff --git a/docs/versioned_docs/version-2.5/20-usage/repo-list.png b/docs/versioned_docs/version-2.5/20-usage/repo-list.png deleted file mode 100644 index b47380087..000000000 Binary files a/docs/versioned_docs/version-2.5/20-usage/repo-list.png and /dev/null differ diff --git a/docs/versioned_docs/version-2.5/30-administration/00-deployment/00-overview.md b/docs/versioned_docs/version-2.5/30-administration/00-deployment/00-overview.md deleted file mode 100644 index bdb64a594..000000000 --- a/docs/versioned_docs/version-2.5/30-administration/00-deployment/00-overview.md +++ /dev/null @@ -1,90 +0,0 @@ -# Deployment - -A Woodpecker deployment consists of two parts: - -- A server which is the heart of Woodpecker and ships the web interface. -- Next to one server, you can deploy any number of agents which will run the pipelines. - -Each agent is able to process one pipeline step by default. -If you have four agents installed and connected to the Woodpecker server, your system will process four workflows in parallel. - -:::tip -You can add more agents to increase the number of parallel workflows or set the agent's `WOODPECKER_MAX_WORKFLOWS=1` environment variable to increase the number of parallel workflows for that agent. -::: - -## Which version of Woodpecker should I use? - -Woodpecker is having two different kinds of releases: **stable** and **next**. - -### Stable releases - -We release a new version every four weeks and will release the current state of the `main` branch. -If there are security fixes or critical bug fixes, we'll release them directly. -There are no backports or similar. - -#### Versioning - -We use [Semantic Versioning](https://semver.org/) to be able, -to communicate when admins have to do manual migration steps and when they can just bump versions up. - -#### Breaking changes - -As of semver guidelines, breaking changes will be released as a major version. We will hold back -breaking changes to not release many majors each containing just a few breaking changes. -Prior to the release of a major version, a release candidate (RC) will be published to allow easy testing, -the actual release will be about a week later. - -## Hardware Requirements - -Below are minimal resources requirements for Woodpecker components itself: - -| Component | Memory | CPU | -| --------- | ------ | --- | -| Server | 200 MB | 1 | -| Agent | 32 MB | 1 | - -Note, that those values do not include the operating system or workload (pipelines execution) resources consumption. - -In addition you need at least some kind of database which requires additional resources depending on the selected database system. - -## Installation - -You can install Woodpecker on multiple ways: - -- Using [docker-compose](./10-docker-compose.md) with the official [container images](./10-docker-compose.md#docker-images) -- Using [Kubernetes](./20-kubernetes.md) via the Woodpecker Helm chart -- Using binaries, DEBs or RPMs you can download from [latest release](https://github.com/woodpecker-ci/woodpecker/releases/latest) - -## Authentication - -Authentication is done using OAuth and is delegated to your forge which is configured using environment variables. - -See the complete reference for all supported forges [here](../11-forges/11-overview.md). - -## Database - -By default Woodpecker uses a SQLite database which requires zero installation or configuration. See the [database settings](../30-database.md) page to further configure it or use MySQL or Postgres. - -## SSL - -Woodpecker supports SSL configuration by using Let's encrypt or by using own certificates. See the [SSL guide](../60-ssl.md). You can also put it behind a [reverse proxy](#behind-a-proxy) - -## Metrics - -A [Prometheus endpoint](../90-prometheus.md) is exposed. - -## Behind a proxy - -See the [proxy guide](../70-proxy.md) if you want to see a setup behind Apache, Nginx, Caddy or ngrok. - -In the case you need to use Woodpecker with a URL path prefix (like: ), add the root path to [`WOODPECKER_HOST`](../10-server-config.md#woodpecker_host). - -## Third-party installation methods - -:::info -These installation methods are not officially supported. If you experience issues with them, please open issues in the specific repositories. -::: - -- Using [NixOS](./30-nixos.md) via the [NixOS module](https://search.nixos.org/options?channel=unstable&size=200&sort=relevance&query=woodpecker) -- [Using YunoHost](https://apps.yunohost.org/app/woodpecker) -- [On Cloudron](https://www.cloudron.io/store/org.woodpecker_ci.cloudronapp.html) diff --git a/docs/versioned_docs/version-2.5/30-administration/11-forges/11-overview.md b/docs/versioned_docs/version-2.5/30-administration/11-forges/11-overview.md deleted file mode 100644 index 4446896f0..000000000 --- a/docs/versioned_docs/version-2.5/30-administration/11-forges/11-overview.md +++ /dev/null @@ -1,13 +0,0 @@ -# Forges - -## Supported features - -| Feature | [GitHub](20-github.md) | [Gitea / Forgejo](30-gitea.md) | [Gitlab](40-gitlab.md) | [Bitbucket](50-bitbucket.md) | [Bitbucket Datacenter](60-bitbucket_datacenter.md) | -| ------------------------------------------------------------- | :--------------------: | :----------------------------: | :--------------------: | :--------------------------: | :------------------------------------------------: | -| Event: Push | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | -| Event: Tag | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | -| Event: Pull-Request | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | -| Event: Release | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :x: | -| Event: Deploy | :white_check_mark: | :x: | :x: | :x: | :x: | -| [Multiple workflows](../../20-usage/25-workflows.md) | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | -| [when.path filter](../../20-usage/20-workflow-syntax.md#path) | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :x: | diff --git a/docs/versioned_docs/version-2.8/10-intro/index.md b/docs/versioned_docs/version-2.8/10-intro/index.md new file mode 100644 index 000000000..1d41cf6a4 --- /dev/null +++ b/docs/versioned_docs/version-2.8/10-intro/index.md @@ -0,0 +1,26 @@ +# Welcome to Woodpecker + +Woodpecker is a CI/CD tool. It is designed to be lightweight, simple to use and fast. Before we dive into the details, let's have a look at some of the basics. + +## Have you ever heard of CI/CD or pipelines? + +Don't worry if you haven't. We'll guide you through the basics. CI/CD stands for Continuous Integration and Continuous Deployment. It's basically like a conveyor belt that moves your code from development to production doing all kinds of +checks, tests and routines along the way. A typical pipeline might include the following steps: + +1. Running tests +2. Building your application +3. Deploying your application + +[Have a deeper look into the idea of CI/CD](https://www.redhat.com/en/topics/devops/what-is-ci-cd) + +## Do you know containers? + +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? + +Then you might want to jump directly into it and [start creating your first pipelines](../20-usage/10-intro.md). + +## Want to start from scratch and deploy your own Woodpecker instance? + +Woodpecker is [pretty lightweight](../30-administration/00-getting-started.md#hardware-requirements) and will even run on your Raspberry Pi. You can follow the [deployment guide](../30-administration/00-getting-started.md) to set up your own Woodpecker instance. diff --git a/docs/versioned_docs/version-2.8/20-usage/10-intro.md b/docs/versioned_docs/version-2.8/20-usage/10-intro.md new file mode 100644 index 000000000..9c4cb3c21 --- /dev/null +++ b/docs/versioned_docs/version-2.8/20-usage/10-intro.md @@ -0,0 +1,109 @@ +# Your first pipeline + +Let's get started and create your first pipeline. + +## 1. Repository Activation + +To activate your repository in Woodpecker navigate to the repository list and `New repository`. You will see a list of repositories from your forge (GitHub, Gitlab, ...) which can be activated with a simple click. + +![new repository list](repo-new.png) + +To enable a repository in Woodpecker you must have `Admin` rights on that repository, so that Woodpecker can add something +that is called a webhook (Woodpecker needs it to know about actions like pushes, pull requests, tags, etc.). + +## 2. Define first workflow + +After enabling a repository Woodpecker will listen for changes in your repository. When a change is detected, Woodpecker will check for a pipeline configuration. So let's create a file at `.woodpecker/my-first-workflow.yaml` inside your repository: + +```yaml title=".woodpecker/my-first-workflow.yaml" +when: + - event: push + branch: main + +steps: + - name: build + image: debian + commands: + - echo "This is the build step" + - echo "binary-data-123" > executable + - name: a-test-step + image: golang:1.16 + commands: + - echo "Testing ..." + - ./executable +``` + +**So what did we do here?** + +1. We defined your first workflow file `my-first-workflow.yaml`. +2. This workflow will be executed when a push event happens on the `main` branch, + because we added a filter using the `when` section: + + ```diff + + when: + + - event: push + + branch: main + + ... + ``` + +3. We defined two steps: `build` and `a-test-step` + +The steps are executed in the order they are defined, so `build` will be executed first and then `a-test-step`. + +In the `build` step we use the `debian` image and build a "binary file" called `executable`. + +In the `a-test-step` we use the `golang:1.16` image and run the `executable` file to test it. + +You can use any image from registries like the [Docker Hub](https://hub.docker.com/search?type=image) you have access to: + +```diff + steps: + - name: build +- image: debian ++ image: mycompany/image-with-awscli + commands: + - aws help +``` + +## 3. Push the file and trigger first pipeline + +If you push this file to your repository now, Woodpecker will already execute your first pipeline. + +You can check the pipeline execution in the Woodpecker UI by navigating to the `Pipelines` section of your repository. + +![pipeline view](./pipeline.png) + +As you probably noticed, there is another step in called `clone` which is executed before your steps. This step clones your repository into a folder called `workspace` which is available throughout all steps. + +This for example allows the first step to build your application using your source code and as the second step will receive +the same workspace it can use the previously built binary and test it. + +## 4. Use a plugin for reusable tasks + +Sometimes you have some tasks that you need to do in every project. For example, deploying to Kubernetes or sending a Slack message. Therefore you can use one of the [official and community plugins](/plugins) or simply [create your own](./51-plugins/20-creating-plugins.md). + +If you want to get a Slack notification after your pipeline has finished, you can add a Slack plugin to your pipeline: + +```yaml +--- +- name: notify me on Slack + image: plugins/slack + settings: + channel: developers + username: woodpecker + password: + from_secret: slack_token + when: + status: [success, failure] # This will execute the step on success and failure +``` + +To configure a plugin you can use the `settings` section. + +Sometime you need to provide secrets to the plugin. You can do this by using the `from_secret` key. The secret must be defined in the Woodpecker UI. You can find more information about secrets [here](./40-secrets.md). + +Similar to the `when` section at the top of the file which is for the complete workflow, you can use the `when` section for each step to define when a step should be executed. + +Learn more about [plugins](./51-plugins/51-overview.md). + +As you now have a basic understanding of how to create a pipeline, you can dive deeper into the [workflow syntax](./20-workflow-syntax.md) and [plugins](./51-plugins/51-overview.md). diff --git a/docs/versioned_docs/version-2.8/20-usage/100-troubleshooting.md b/docs/versioned_docs/version-2.8/20-usage/100-troubleshooting.md new file mode 100644 index 000000000..b961530f4 --- /dev/null +++ b/docs/versioned_docs/version-2.8/20-usage/100-troubleshooting.md @@ -0,0 +1,37 @@ +# Troubleshooting + +## How to debug clone issues + +(And what to do with an error message like `fatal: could not read Username for 'https://': No such device or address`) + +This error can have multiple causes. If you use internal repositories you might have to enable `WOODPECKER_AUTHENTICATE_PUBLIC_REPOS`: + +```ini +WOODPECKER_AUTHENTICATE_PUBLIC_REPOS=true +``` + +If that does not work, try to make sure the container can reach your git server. In order to do that disable git checkout and make the container "hang": + +```yaml +skip_clone: true + +steps: + build: + image: debian:stable-backports + commands: + - apt update + - apt install -y inetutils-ping wget + - ping -c 4 git.example.com + - wget git.example.com + - sleep 9999999 +``` + +Get the container id using `docker ps` and copy the id from the first column. Enter the container with: `docker exec -it 1234asdf bash` (replace `1234asdf` with the docker id). Then try to clone the git repository with the commands from the failing pipeline: + +```bash +git init +git remote add origin https://git.example.com/username/repo.git +git fetch --no-tags origin +refs/heads/branch: +``` + +(replace the url AND the branch with the correct values, use your username and password as log in values) diff --git a/docs/versioned_docs/version-2.5/20-usage/15-terminology/architecture.excalidraw b/docs/versioned_docs/version-2.8/20-usage/15-terminology/architecture.excalidraw similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/15-terminology/architecture.excalidraw rename to docs/versioned_docs/version-2.8/20-usage/15-terminology/architecture.excalidraw diff --git a/docs/versioned_docs/version-2.5/20-usage/15-terminology/architecture.svg b/docs/versioned_docs/version-2.8/20-usage/15-terminology/architecture.svg similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/15-terminology/architecture.svg rename to docs/versioned_docs/version-2.8/20-usage/15-terminology/architecture.svg diff --git a/docs/versioned_docs/version-2.5/20-usage/15-terminology/index.md b/docs/versioned_docs/version-2.8/20-usage/15-terminology/index.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/15-terminology/index.md rename to docs/versioned_docs/version-2.8/20-usage/15-terminology/index.md index 5e9d8e5de..f05f18207 100644 --- a/docs/versioned_docs/version-2.5/20-usage/15-terminology/index.md +++ b/docs/versioned_docs/version-2.8/20-usage/15-terminology/index.md @@ -1,13 +1,5 @@ # Terminology -## Woodpecker architecture - -![Woodpecker architecture](architecture.svg) - -## Pipeline, workflow & step - -![Relation between pipelines, workflows and steps](pipeline-workflow-step.svg) - ## Glossary - **Woodpecker CI**: The project name around Woodpecker. @@ -33,6 +25,14 @@ - **Status**: Status refers to the outcome of a step or [workflow][Workflow] after it has been executed, determined by the internal command exit code. At the end of a [workflow][Workflow], its status is sent to the [forge][Forge]. - **Service extension**: Some parts of Woodpecker internal services like secrets storage or config fetcher can be replaced through service extensions. +## Woodpecker architecture + +![Woodpecker architecture](architecture.svg) + +## Pipeline, workflow & step + +![Relation between pipelines, workflows and steps](pipeline-workflow-step.svg) + ## Pipeline events - `push`: A push event is triggered when a commit is pushed to a branch. diff --git a/docs/versioned_docs/version-2.5/20-usage/15-terminology/pipeline-workflow-step.excalidraw b/docs/versioned_docs/version-2.8/20-usage/15-terminology/pipeline-workflow-step.excalidraw similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/15-terminology/pipeline-workflow-step.excalidraw rename to docs/versioned_docs/version-2.8/20-usage/15-terminology/pipeline-workflow-step.excalidraw diff --git a/docs/versioned_docs/version-2.5/20-usage/15-terminology/pipeline-workflow-step.svg b/docs/versioned_docs/version-2.8/20-usage/15-terminology/pipeline-workflow-step.svg similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/15-terminology/pipeline-workflow-step.svg rename to docs/versioned_docs/version-2.8/20-usage/15-terminology/pipeline-workflow-step.svg diff --git a/docs/versioned_docs/version-2.5/20-usage/20-workflow-syntax.md b/docs/versioned_docs/version-2.8/20-usage/20-workflow-syntax.md similarity index 97% rename from docs/versioned_docs/version-2.5/20-usage/20-workflow-syntax.md rename to docs/versioned_docs/version-2.8/20-usage/20-workflow-syntax.md index 7b966fc48..3aac2176a 100644 --- a/docs/versioned_docs/version-2.5/20-usage/20-workflow-syntax.md +++ b/docs/versioned_docs/version-2.8/20-usage/20-workflow-syntax.md @@ -6,6 +6,11 @@ The Workflow section defines a list of steps to build, test and deploy your code An exception to this rule are steps with a [`status: [failure]`](#status) condition, which ensures that they are executed in the case of a failed run. ::: +:::note +We support most of YAML 1.2, but preserve some behavior from 1.1 for backward compatibility. +Read more at: [https://github.com/go-yaml/yaml](https://github.com/go-yaml/yaml/tree/v3) +::: + Example steps: ```yaml @@ -518,7 +523,9 @@ For more details check the [services docs](./60-services.md). ## `workspace` -The workspace defines the shared volume and working directory shared by all workflow steps. The default workspace matches the pattern `/woodpecker/src/github.com/octocat/hello-world`, based on your repository URL. +The workspace defines the shared volume and working directory shared by all workflow steps. +The default workspace base is `/woodpecker` and the path is extended with the repository URL (`src/{url-without-schema}`). +So an example would be `/woodpecker/src/github.com/octocat/hello-world`. The workspace can be customized using the workspace block in the YAML file: @@ -535,6 +542,10 @@ The workspace can be customized using the workspace block in the YAML file: - go test ``` +:::note +Plugins will always have the workspace base at `/woodpecker` +::: + The base attribute defines a shared base volume available to all steps. This ensures your source code, dependencies and compiled binaries are persisted and shared between steps. ```diff diff --git a/docs/versioned_docs/version-2.5/20-usage/25-workflows.md b/docs/versioned_docs/version-2.8/20-usage/25-workflows.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/25-workflows.md rename to docs/versioned_docs/version-2.8/20-usage/25-workflows.md diff --git a/docs/versioned_docs/version-2.5/20-usage/30-matrix-workflows.md b/docs/versioned_docs/version-2.8/20-usage/30-matrix-workflows.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/30-matrix-workflows.md rename to docs/versioned_docs/version-2.8/20-usage/30-matrix-workflows.md diff --git a/docs/versioned_docs/version-2.5/20-usage/40-secrets.md b/docs/versioned_docs/version-2.8/20-usage/40-secrets.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/40-secrets.md rename to docs/versioned_docs/version-2.8/20-usage/40-secrets.md diff --git a/docs/versioned_docs/version-2.5/20-usage/41-registries.md b/docs/versioned_docs/version-2.8/20-usage/41-registries.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/41-registries.md rename to docs/versioned_docs/version-2.8/20-usage/41-registries.md diff --git a/docs/versioned_docs/version-2.5/20-usage/45-cron.md b/docs/versioned_docs/version-2.8/20-usage/45-cron.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/45-cron.md rename to docs/versioned_docs/version-2.8/20-usage/45-cron.md diff --git a/docs/versioned_docs/version-2.5/20-usage/50-environment.md b/docs/versioned_docs/version-2.8/20-usage/50-environment.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/50-environment.md rename to docs/versioned_docs/version-2.8/20-usage/50-environment.md diff --git a/docs/versioned_docs/version-2.5/20-usage/51-plugins/20-creating-plugins.md b/docs/versioned_docs/version-2.8/20-usage/51-plugins/20-creating-plugins.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/51-plugins/20-creating-plugins.md rename to docs/versioned_docs/version-2.8/20-usage/51-plugins/20-creating-plugins.md diff --git a/docs/versioned_docs/version-2.5/20-usage/51-plugins/51-overview.md b/docs/versioned_docs/version-2.8/20-usage/51-plugins/51-overview.md similarity index 54% rename from docs/versioned_docs/version-2.5/20-usage/51-plugins/51-overview.md rename to docs/versioned_docs/version-2.8/20-usage/51-plugins/51-overview.md index ab8db3df3..8dc3c6d63 100644 --- a/docs/versioned_docs/version-2.5/20-usage/51-plugins/51-overview.md +++ b/docs/versioned_docs/version-2.8/20-usage/51-plugins/51-overview.md @@ -4,6 +4,24 @@ Plugins are pipeline steps that perform pre-defined tasks and are configured as They are automatically pulled from the default container registry the agent's have configured. +```dockerfile title="Dockerfile" +FROM laszlocloud/kubectl +COPY deploy /usr/local/deploy +ENTRYPOINT ["/usr/local/deploy"] +``` + +```bash title="deploy" +kubectl apply -f $PLUGIN_TEMPLATE +``` + +```yaml title=".woodpecker.yaml" +steps: + - name: deploy-to-k8s + image: laszlocloud/my-k8s-plugin + settings: + template: config/k8s/service.yaml +``` + Example pipeline using the Docker and Slack plugins: ```yaml @@ -29,6 +47,12 @@ steps: ## Plugin Isolation 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. + +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 +anymore. The container then cannot access secrets with plugin filter anymore and the containers won't be privileged without explicit definition. ## Finding Plugins diff --git a/docs/versioned_docs/version-2.5/20-usage/51-plugins/_category_.yaml b/docs/versioned_docs/version-2.8/20-usage/51-plugins/_category_.yaml similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/51-plugins/_category_.yaml rename to docs/versioned_docs/version-2.8/20-usage/51-plugins/_category_.yaml diff --git a/docs/versioned_docs/version-2.5/20-usage/60-services.md b/docs/versioned_docs/version-2.8/20-usage/60-services.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/60-services.md rename to docs/versioned_docs/version-2.8/20-usage/60-services.md diff --git a/docs/versioned_docs/version-2.5/20-usage/70-volumes.md b/docs/versioned_docs/version-2.8/20-usage/70-volumes.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/70-volumes.md rename to docs/versioned_docs/version-2.8/20-usage/70-volumes.md diff --git a/docs/versioned_docs/version-2.5/20-usage/72-linter.md b/docs/versioned_docs/version-2.8/20-usage/72-linter.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/72-linter.md rename to docs/versioned_docs/version-2.8/20-usage/72-linter.md diff --git a/docs/versioned_docs/version-2.5/20-usage/75-project-settings.md b/docs/versioned_docs/version-2.8/20-usage/75-project-settings.md similarity index 74% rename from docs/versioned_docs/version-2.5/20-usage/75-project-settings.md rename to docs/versioned_docs/version-2.8/20-usage/75-project-settings.md index d57b3a932..12b505dbd 100644 --- a/docs/versioned_docs/version-2.5/20-usage/75-project-settings.md +++ b/docs/versioned_docs/version-2.8/20-usage/75-project-settings.md @@ -25,10 +25,9 @@ Only activate this option if you trust all users who have push access to your re Otherwise, these users will be able to steal secrets that are only available for `deploy` events. ::: -## Protected +## Require approval for -Every pipeline initiated by an webhook event needs to be approved by a project members with push permissions before being executed. -The protected option can be used as an additional review process before running potentially harmful pipelines. Especially if pipelines can be executed by third-parties through pull-requests. +To prevent malicious pipelines from extracting secrets or running harmful commands or to prevent accidental pipeline runs, you can require approval for an additional review process. Depending on the enabled option, a pipeline will be put on hold after creation and will only continue after approval. The default restrictive setting is `All pull requests`. ## Trusted @@ -40,16 +39,9 @@ Only server admins can set this option. If you are not a server admin this optio ::: -## Only inject Git credentials into trusted clone plugins +## Only inject netrc credentials into trusted containers -The clone step may require Git credentials (e.g. for private repos) which are injected via `netrc`. - -By default, they are only injected into trusted clone plugins listed in the env var `WOODPECKER_PLUGINS_TRUSTED_CLONE`. -If this option is disabled, the Git credentials are injected into every clone plugin, regardless of whether it is trusted or not. - -:::note -This option has no effect on steps other than the clone step. -::: +Cloning pipeline step may need git credentials. They are injected via netrc. By default, they're only injected if this option is enabled, the repo is trusted ([see above](#trusted)) or the image is a trusted clone image. If you uncheck the option, git credentials will be injected into any container in clone step. ## Project visibility diff --git a/docs/versioned_docs/version-2.5/20-usage/80-badges.md b/docs/versioned_docs/version-2.8/20-usage/80-badges.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/80-badges.md rename to docs/versioned_docs/version-2.8/20-usage/80-badges.md diff --git a/docs/versioned_docs/version-2.5/20-usage/90-advanced-usage.md b/docs/versioned_docs/version-2.8/20-usage/90-advanced-usage.md similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/90-advanced-usage.md rename to docs/versioned_docs/version-2.8/20-usage/90-advanced-usage.md diff --git a/docs/versioned_docs/version-2.5/20-usage/_category_.yaml b/docs/versioned_docs/version-2.8/20-usage/_category_.yaml similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/_category_.yaml rename to docs/versioned_docs/version-2.8/20-usage/_category_.yaml diff --git a/docs/versioned_docs/version-2.5/20-usage/cron-settings.png b/docs/versioned_docs/version-2.8/20-usage/cron-settings.png similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/cron-settings.png rename to docs/versioned_docs/version-2.8/20-usage/cron-settings.png diff --git a/docs/versioned_docs/version-2.5/20-usage/linter-warnings-errors.png b/docs/versioned_docs/version-2.8/20-usage/linter-warnings-errors.png similarity index 100% rename from docs/versioned_docs/version-2.5/20-usage/linter-warnings-errors.png rename to docs/versioned_docs/version-2.8/20-usage/linter-warnings-errors.png diff --git a/docs/versioned_docs/version-2.8/20-usage/pipeline.png b/docs/versioned_docs/version-2.8/20-usage/pipeline.png new file mode 100644 index 000000000..dd4063c9a Binary files /dev/null and b/docs/versioned_docs/version-2.8/20-usage/pipeline.png differ diff --git a/docs/versioned_docs/version-2.8/20-usage/project-settings.png b/docs/versioned_docs/version-2.8/20-usage/project-settings.png new file mode 100644 index 000000000..f3ce025f2 Binary files /dev/null and b/docs/versioned_docs/version-2.8/20-usage/project-settings.png differ diff --git a/docs/versioned_docs/version-2.8/20-usage/repo-new.png b/docs/versioned_docs/version-2.8/20-usage/repo-new.png new file mode 100644 index 000000000..e6136bc12 Binary files /dev/null and b/docs/versioned_docs/version-2.8/20-usage/repo-new.png differ diff --git a/docs/versioned_docs/version-2.8/30-administration/00-getting-started.md b/docs/versioned_docs/version-2.8/30-administration/00-getting-started.md new file mode 100644 index 000000000..668a38792 --- /dev/null +++ b/docs/versioned_docs/version-2.8/30-administration/00-getting-started.md @@ -0,0 +1,59 @@ +# Gettings started + +A Woodpecker deployment consists of two parts: + +- A server which is the heart of Woodpecker and ships the web interface. +- Next to one server, you can deploy any number of agents which will run the pipelines. + +Each agent is able to process one [workflow](../20-usage/15-terminology/index.md) by default. If you have 4 agents installed and connected to the Woodpecker server, your system will process four workflows (not pipelines) in parallel. + +:::tip +You can add more agents to increase the number of parallel workflows or set the agent's `WOODPECKER_MAX_WORKFLOWS=1` environment variable to increase the number of parallel workflows per agent. +::: + +## Which version of Woodpecker should I use? + +Woodpecker is having two different kinds of releases: **stable** and **next**. + +Find more information about the different versions [here](/versions). + +## Hardware Requirements + +Below are minimal resources requirements for Woodpecker components itself: + +| Component | Memory | CPU | +| --------- | ------ | --- | +| Server | 200 MB | 1 | +| Agent | 32 MB | 1 | + +Note, that those values do not include the operating system or workload (pipelines execution) resource consumption. + +In addition you need at least some kind of database which requires additional resources depending on the selected database system. + +## Installation + +You can install Woodpecker on multiple ways. If you are not sure which one to choose, we recommend using the [docker-compose](./05-deployment-methods/10-docker-compose.md) method for the beginning: + +- Using [docker-compose](./05-deployment-methods/10-docker-compose.md) with the official [container images](./05-deployment-methods/10-docker-compose.md#docker-images) +- Using [Kubernetes](./05-deployment-methods/20-kubernetes.md) via the Woodpecker Helm chart +- Using binaries, DEBs or RPMs you can download from [latest release](https://github.com/woodpecker-ci/woodpecker/releases/latest) +- Or using a [third-party installation method](./05-deployment-methods/30-third-party.md) + +## Database + +By default Woodpecker uses a SQLite database which requires zero installation or configuration. See the [database settings](./10-database.md) page if you want to use a different database system like MySQL or PostgreSQL. + +## 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. + +## Configuration + +Check the [server configuration](./10-server-config.md) and [agent configuration](./15-agent-config.md) pages to see if you need to adjust any additional parts and after that you should be ready to start with [your first pipeline](../20-usage/10-intro.md). + +## Agent + +The agent is the worker which executes the [workflows](../20-usage/15-terminology/index.md). +Woodpecker agents can execute work using a [backend](../20-usage/15-terminology/index.md) like [docker](./22-backends/10-docker.md) or [kubernetes](./22-backends/40-kubernetes.md). +By default if you choose to deploy an agent using [docker-compose](./05-deployment-methods/10-docker-compose.md) the agent simply use docker for the backend as well. +So nothing to worry about here. If you still prefer to adjust the agent to your needs, check the [agent configuration](./15-agent-config.md) page. diff --git a/docs/versioned_docs/version-2.5/30-administration/00-deployment/10-docker-compose.md b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/10-docker-compose.md similarity index 94% rename from docs/versioned_docs/version-2.5/30-administration/00-deployment/10-docker-compose.md rename to docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/10-docker-compose.md index a9c2bb6ab..5af7e85fc 100644 --- a/docs/versioned_docs/version-2.5/30-administration/00-deployment/10-docker-compose.md +++ b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/10-docker-compose.md @@ -67,7 +67,7 @@ They can be configured with `*_ADDR` variables: + - WOODPECKER_SERVER_ADDR=${WOODPECKER_HTTP_ADDR} ``` -Reverse proxying can also be [configured for gRPC](../70-proxy.md#caddy). If the agents are connecting over the internet, it should also be SSL encrypted. The agent then needs to be configured to be secure: +Reverse proxying can also be [configured for gRPC](../40-advanced/10-proxy.md#caddy). If the agents are connecting over the internet, it should also be SSL encrypted. The agent then needs to be configured to be secure: ```diff title="docker-compose.yaml" version: '3' diff --git a/docs/versioned_docs/version-2.5/30-administration/00-deployment/20-kubernetes.md b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/20-kubernetes.md similarity index 100% rename from docs/versioned_docs/version-2.5/30-administration/00-deployment/20-kubernetes.md rename to docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/20-kubernetes.md diff --git a/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/30-third-party.md b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/30-third-party.md new file mode 100644 index 000000000..acad9c0fd --- /dev/null +++ b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/30-third-party.md @@ -0,0 +1,12 @@ +# Third-party installation methods + +:::info +These installation methods are not officially supported. If you experience issues with them, please open issues in the specific repositories. +::: + +- [Using NixOS](./40-nixos.md) via the [NixOS module](https://search.nixos.org/options?channel=unstable&size=200&sort=relevance&query=woodpecker) +- [On Alpine Edge](https://pkgs.alpinelinux.org/packages?name=woodpecker&branch=edge&repo=&arch=&maintainer=) +- [On Arch Linux](https://archlinux.org/packages/?q=woodpecker) +- [On openSUSE](https://software.opensuse.org/package/woodpecker) +- [Using YunoHost](https://apps.yunohost.org/app/woodpecker) +- [On Cloudron](https://www.cloudron.io/store/org.woodpecker_ci.cloudronapp.html) diff --git a/docs/versioned_docs/version-2.5/30-administration/00-deployment/30-nixos.md b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/40-nixos.md similarity index 100% rename from docs/versioned_docs/version-2.5/30-administration/00-deployment/30-nixos.md rename to docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/40-nixos.md diff --git a/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/_category_.yaml b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/_category_.yaml new file mode 100644 index 000000000..3907838b0 --- /dev/null +++ b/docs/versioned_docs/version-2.8/30-administration/05-deployment-methods/_category_.yaml @@ -0,0 +1,3 @@ +label: 'Deployment methods' +collapsible: true +collapsed: true diff --git a/docs/versioned_docs/version-2.5/30-administration/30-database.md b/docs/versioned_docs/version-2.8/30-administration/10-database.md similarity index 100% rename from docs/versioned_docs/version-2.5/30-administration/30-database.md rename to docs/versioned_docs/version-2.8/30-administration/10-database.md diff --git a/docs/versioned_docs/version-2.5/30-administration/10-server-config.md b/docs/versioned_docs/version-2.8/30-administration/10-server-config.md similarity index 97% rename from docs/versioned_docs/version-2.5/30-administration/10-server-config.md rename to docs/versioned_docs/version-2.8/30-administration/10-server-config.md index 8bd7d49c2..ec5abeb09 100644 --- a/docs/versioned_docs/version-2.5/30-administration/10-server-config.md +++ b/docs/versioned_docs/version-2.8/30-administration/10-server-config.md @@ -360,6 +360,8 @@ a user can log into Woodpecker, without re-authentication. Docker images to run in privileged mode. Only change if you are sure what you do! +You should specify the tag of your images too, as this enforces exact matches. + + ## `next` +- Deprecated `gated` repo settings option, use `require-approval` - Deprecated `steps.[name].group` in favor of `steps.[name].depends_on` (see [workflow syntax](./20-usage/20-workflow-syntax.md#depends_on) to learn how to set dependencies) - Removed `WOODPECKER_ROOT_PATH` and `WOODPECKER_ROOT_URL` config variables. Use `WOODPECKER_HOST` with a path instead - Pipelines without a config file will now be skipped instead of failing @@ -30,7 +38,7 @@ Some versions need some changes to the server configuration or the pipeline conf ## 1.0.0 -- The signature used to verify extension calls (like those used for the [config-extension](./30-administration/100-external-configuration-api.md)) done by the Woodpecker server switched from using a shared-secret HMac to an ed25519 key-pair. Read more about it at the [config-extensions](./30-administration/100-external-configuration-api.md) documentation. +- The signature used to verify extension calls (like those used for the [config-extension](./30-administration/40-advanced/100-external-configuration-api.md)) done by the Woodpecker server switched from using a shared-secret HMac to an ed25519 key-pair. Read more about it at the [config-extensions](./30-administration/40-advanced/100-external-configuration-api.md) documentation. - Refactored support for old agent filter labels and expressions. Learn how to use the new [filter](./20-usage/20-workflow-syntax.md#labels) - Renamed step environment variable `CI_SYSTEM_ARCH` to `CI_SYSTEM_PLATFORM`. Same applies for the cli exec variable. - Renamed environment variables `CI_BUILD_*` and `CI_PREV_BUILD_*` to `CI_PIPELINE_*` and `CI_PREV_PIPELINE_*`, old ones are still available but deprecated diff --git a/docs/versioned_docs/version-2.5/92-awesome.md b/docs/versioned_docs/version-2.8/92-awesome.md similarity index 97% rename from docs/versioned_docs/version-2.5/92-awesome.md rename to docs/versioned_docs/version-2.8/92-awesome.md index b9b593580..920341d33 100644 --- a/docs/versioned_docs/version-2.5/92-awesome.md +++ b/docs/versioned_docs/version-2.8/92-awesome.md @@ -43,7 +43,7 @@ If you have some missing resources, please feel free to [open a pull-request](ht - [Setup Gitea with Woodpecker CI](https://containers.fan/posts/setup-gitea-with-woodpecker-ci/) - [Step-by-step guide to modern, secure and Open-source CI setup](https://devforth.io/blog/step-by-step-guide-to-modern-secure-ci-setup/) -- [Using Woodpecker CI for my static sites](https://web.archive.org/web/20240212182516/https://jan.wildeboer.net/2022/07/Woodpecker-CI-Jekyll/) +- [Using Woodpecker CI for my static sites](https://jan.wildeboer.net/2022/07/Woodpecker-CI-Jekyll/) - [Woodpecker CI @ Codeberg](https://www.sarkasti.eu/articles/post/woodpecker/) - [Deploy Docker/Compose using Woodpecker CI](https://hinty.io/vverenko/deploy-docker-compose-using-woodpecker-ci/) - [Installing Woodpecker CI in your personal homelab](https://pwa.io/articles/installing-woodpecker-in-your-homelab/) diff --git a/docs/versioned_docs/version-2.5/92-development/01-getting-started.md b/docs/versioned_docs/version-2.8/92-development/01-getting-started.md similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/01-getting-started.md rename to docs/versioned_docs/version-2.8/92-development/01-getting-started.md diff --git a/docs/versioned_docs/version-2.5/92-development/02-core-ideas.md b/docs/versioned_docs/version-2.8/92-development/02-core-ideas.md similarity index 93% rename from docs/versioned_docs/version-2.5/92-development/02-core-ideas.md rename to docs/versioned_docs/version-2.8/92-development/02-core-ideas.md index 8e0d6e292..a88470f0a 100644 --- a/docs/versioned_docs/version-2.5/92-development/02-core-ideas.md +++ b/docs/versioned_docs/version-2.8/92-development/02-core-ideas.md @@ -8,7 +8,7 @@ ## Addons and extensions If you are wondering whether your contribution will be accepted to be merged in the Woodpecker core, or whether it's better to write an -[addon forge](../30-administration/11-forges/100-addon.md), [extension](../30-administration/100-external-configuration-api.md) or an +[addon forge](../30-administration/11-forges/100-addon.md), [extension](../30-administration/40-advanced/100-external-configuration-api.md) or an [external custom backend](../30-administration/22-backends/50-custom-backends.md), please check these points: - Is your change very specific to your setup and unlikely to be used by anyone else? diff --git a/docs/versioned_docs/version-2.5/92-development/03-ui.md b/docs/versioned_docs/version-2.8/92-development/03-ui.md similarity index 98% rename from docs/versioned_docs/version-2.5/92-development/03-ui.md rename to docs/versioned_docs/version-2.8/92-development/03-ui.md index e8999b0be..6a01584c2 100644 --- a/docs/versioned_docs/version-2.5/92-development/03-ui.md +++ b/docs/versioned_docs/version-2.8/92-development/03-ui.md @@ -36,4 +36,4 @@ The following list contains some tools and frameworks used by the Woodpecker UI. Woodpecker uses [Vue I18n](https://vue-i18n.intlify.dev/) as translation library. New translations have to be added to `web/src/assets/locales/en.json`. The English source file will be automatically imported into [Weblate](https://translate.woodpecker-ci.org/) (the translation system used by Woodpecker) where all other languages will be translated by the community based on the English source. You must not provide translations except English in PRs, otherwise weblate could put git into conflicts (when someone has translated in that language file and changes are not into main branch yet) -For more information about translations see [Translations](./07-translations.md). +For more information about translations see [Translations](./08-translations.md). diff --git a/docs/versioned_docs/version-2.5/92-development/04-docs.md b/docs/versioned_docs/version-2.8/92-development/04-docs.md similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/04-docs.md rename to docs/versioned_docs/version-2.8/92-development/04-docs.md diff --git a/docs/versioned_docs/version-2.5/92-development/05-architecture.md b/docs/versioned_docs/version-2.8/92-development/05-architecture.md similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/05-architecture.md rename to docs/versioned_docs/version-2.8/92-development/05-architecture.md diff --git a/docs/versioned_docs/version-2.8/92-development/06-conventions.md b/docs/versioned_docs/version-2.8/92-development/06-conventions.md new file mode 100644 index 000000000..e94a90c43 --- /dev/null +++ b/docs/versioned_docs/version-2.8/92-development/06-conventions.md @@ -0,0 +1,7 @@ +# Conventions + +## Database naming + +Database tables are named plural, columns don't have any prefix. + +Example: Table name `agent`, columns `id`, `name`. diff --git a/docs/versioned_docs/version-2.5/92-development/06-guides.md b/docs/versioned_docs/version-2.8/92-development/07-guides.md similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/06-guides.md rename to docs/versioned_docs/version-2.8/92-development/07-guides.md diff --git a/docs/versioned_docs/version-2.5/92-development/07-translations.md b/docs/versioned_docs/version-2.8/92-development/08-translations.md similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/07-translations.md rename to docs/versioned_docs/version-2.8/92-development/08-translations.md diff --git a/docs/versioned_docs/version-2.5/92-development/08-swagger.md b/docs/versioned_docs/version-2.8/92-development/09-swagger.md similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/08-swagger.md rename to docs/versioned_docs/version-2.8/92-development/09-swagger.md diff --git a/docs/versioned_docs/version-2.8/92-development/09-testing.md b/docs/versioned_docs/version-2.8/92-development/09-testing.md new file mode 100644 index 000000000..ba613c108 --- /dev/null +++ b/docs/versioned_docs/version-2.8/92-development/09-testing.md @@ -0,0 +1,81 @@ +# Testing + +## Backend + +### Unit Tests + +[We use default golang unit tests](https://go.dev/doc/tutorial/add-a-test) +with [`"github.com/stretchr/testify/assert"`](https://pkg.go.dev/github.com/stretchr/testify@v1.9.0/assert) to simplify testing. + +### Integration Tests + +### Dummy backend + +There is a special backend called **`dummy`** which does not execute any commands, but emulates how a typical backend should behave. +To enable it you need to build the agent or cli with the `test` build tag. + +An example pipeline config would be: + +```yaml +when: + event: manual + +steps: + - name: echo + image: dummy + commands: echo "hello woodpecker" + environment: + SLEEP: '1s' + +services: + echo: + image: dummy + commands: echo "i am a sevice" +``` + +This could be executed via `woodpecker-cli --log-level trace exec --backend-engine dummy example.yaml`: + +```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 +9:18PM DBG pipeline/pipeline.go:104 > stage CLI=exec StagePos=1 Steps=echo +9:18PM TRC pipeline/backend/dummy/dummy.go:75 > create workflow environment taskUUID=01J10P578JQE6E25VV1EQF0745 +9:18PM DBG pipeline/pipeline.go:176 > prepare CLI=exec step=echo +9:18PM DBG pipeline/pipeline.go:203 > executing CLI=exec step=echo +9:18PM TRC pipeline/backend/dummy/dummy.go:81 > start step echo taskUUID=01J10P578JQE6E25VV1EQF0745 +9:18PM TRC pipeline/backend/dummy/dummy.go:167 > tail logs of step echo taskUUID=01J10P578JQE6E25VV1EQF0745 +9:18PM DBG pipeline/pipeline.go:209 > complete CLI=exec step=echo +[echo:L0:0s] StepName: echo +[echo:L1:0s] StepType: service +[echo:L2:0s] StepUUID: 01J10P578JQE6E25VV1A2DNQN9 +[echo:L3:0s] StepCommands: +[echo:L4:0s] ------------------ +[echo:L5:0s] echo ja +[echo:L6:0s] ------------------ +[echo:L7:0s] 9:18PM DBG pipeline/pipeline.go:176 > prepare CLI=exec step=echo +9:18PM DBG pipeline/pipeline.go:203 > executing CLI=exec step=echo +9:18PM TRC pipeline/backend/dummy/dummy.go:81 > start step echo taskUUID=01J10P578JQE6E25VV1EQF0745 +9:18PM TRC pipeline/backend/dummy/dummy.go:167 > tail logs of step echo taskUUID=01J10P578JQE6E25VV1EQF0745 +[echo:L0:0s] StepName: echo +[echo:L1:0s] StepType: commands +[echo:L2:0s] StepUUID: 01J10P578JQE6E25VV1DFSXX1Y +[echo:L3:0s] StepCommands: +[echo:L4:0s] ------------------ +[echo:L5:0s] echo ja +[echo:L6:0s] ------------------ +[echo:L7:0s] 9:18PM TRC pipeline/backend/dummy/dummy.go:108 > wait for step echo taskUUID=01J10P578JQE6E25VV1EQF0745 +9:18PM TRC pipeline/backend/dummy/dummy.go:187 > stop step echo taskUUID=01J10P578JQE6E25VV1EQF0745 +9:18PM DBG pipeline/pipeline.go:209 > complete CLI=exec step=echo +9:18PM TRC pipeline/backend/dummy/dummy.go:208 > delete workflow environment taskUUID=01J10P578JQE6E25VV1EQF0745 +``` + +There are also environment variables to alter step behaviour: + +- `SLEEP: 10` will let the step wait 10 seconds +- `EXPECT_TYPE` allows to check if a step is a `clone`, `service`, `plugin` or `commands` +- `STEP_START_FAIL: true` if set will simulate a step to fail before actually being started (e.g. happens when the container image can not be pulled) +- `STEP_TAIL_FAIL: true` if set will error when we simulate to read from stdout for logs +- `STEP_EXIT_CODE: 2` if set will be used as exit code, default is 0 +- `STEP_OOM_KILLED: true` simulates a step being killed by memory constrains + +You can let the setup of a whole workflow fail by setting it's UUID to `WorkflowSetupShouldFail`. diff --git a/docs/versioned_docs/version-2.5/92-development/_category_.yaml b/docs/versioned_docs/version-2.8/92-development/_category_.yaml similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/_category_.yaml rename to docs/versioned_docs/version-2.8/92-development/_category_.yaml diff --git a/docs/versioned_docs/version-2.5/92-development/ui-proxy.svg b/docs/versioned_docs/version-2.8/92-development/ui-proxy.svg similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/ui-proxy.svg rename to docs/versioned_docs/version-2.8/92-development/ui-proxy.svg diff --git a/docs/versioned_docs/version-2.5/92-development/vscode-debug.png b/docs/versioned_docs/version-2.8/92-development/vscode-debug.png similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/vscode-debug.png rename to docs/versioned_docs/version-2.8/92-development/vscode-debug.png diff --git a/docs/versioned_docs/version-2.5/92-development/vscode-run-test.png b/docs/versioned_docs/version-2.8/92-development/vscode-run-test.png similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/vscode-run-test.png rename to docs/versioned_docs/version-2.8/92-development/vscode-run-test.png diff --git a/docs/versioned_docs/version-2.5/92-development/woodpecker-architecture.png b/docs/versioned_docs/version-2.8/92-development/woodpecker-architecture.png similarity index 100% rename from docs/versioned_docs/version-2.5/92-development/woodpecker-architecture.png rename to docs/versioned_docs/version-2.8/92-development/woodpecker-architecture.png diff --git a/docs/versioned_docs/version-2.8/pipeline-list.png b/docs/versioned_docs/version-2.8/pipeline-list.png new file mode 100644 index 000000000..f501fe0e6 Binary files /dev/null and b/docs/versioned_docs/version-2.8/pipeline-list.png differ diff --git a/docs/versioned_docs/version-2.5/woodpecker.png b/docs/versioned_docs/version-2.8/woodpecker.png similarity index 100% rename from docs/versioned_docs/version-2.5/woodpecker.png rename to docs/versioned_docs/version-2.8/woodpecker.png diff --git a/docs/versioned_sidebars/version-2.5-sidebars.json b/docs/versioned_sidebars/version-2.8-sidebars.json similarity index 100% rename from docs/versioned_sidebars/version-2.5-sidebars.json rename to docs/versioned_sidebars/version-2.8-sidebars.json diff --git a/docs/versions.json b/docs/versions.json index 9d0c78ccf..62cbcf9ab 100644 --- a/docs/versions.json +++ b/docs/versions.json @@ -1 +1 @@ -["2.7", "2.6", "2.5", "1.0"] +["2.8", "2.7", "2.6", "1.0"] diff --git a/server/api/pipeline.go b/server/api/pipeline.go index 2106fe32e..fa9d4ce6c 100644 --- a/server/api/pipeline.go +++ b/server/api/pipeline.go @@ -22,6 +22,7 @@ import ( "fmt" "net/http" "strconv" + "strings" "time" "github.com/gin-gonic/gin" @@ -116,14 +117,32 @@ func createTmpPipeline(event model.WebhookEvent, commit *model.Commit, user *mod // @Param perPage query int false "for response pagination, max items per page" default(50) // @Param before query string false "only return pipelines before this RFC3339 date" // @Param after query string false "only return pipelines after this RFC3339 date" +// @Param branch query string false "filter pipelines by branch" +// @Param event query string false "filter pipelines by webhook events (comma separated)" +// @Param ref query string false "filter pipelines by strings contained in ref" func GetPipelines(c *gin.Context) { repo := session.Repo(c) - before := c.Query("before") - after := c.Query("after") - filter := new(model.PipelineFilter) + filter := &model.PipelineFilter{ + Branch: c.Query("branch"), + RefContains: c.Query("ref"), + } - if before != "" { + if events := c.Query("event"); events != "" { + eventList := strings.Split(events, ",") + wel := make(model.WebhookEventList, 0, len(eventList)) + for _, event := range events { + we := model.WebhookEvent(event) + if err := we.Validate(); err != nil { + _ = c.AbortWithError(http.StatusBadRequest, err) + return + } + wel = append(wel, we) + } + filter.Events = wel + } + + if before := c.Query("before"); before != "" { beforeDt, err := time.Parse(time.RFC3339, before) if err != nil { _ = c.AbortWithError(http.StatusBadRequest, err) @@ -132,7 +151,7 @@ func GetPipelines(c *gin.Context) { filter.Before = beforeDt.Unix() } - if after != "" { + if after := c.Query("after"); after != "" { afterDt, err := time.Parse(time.RFC3339, after) if err != nil { _ = c.AbortWithError(http.StatusBadRequest, err) diff --git a/server/model/pipeline.go b/server/model/pipeline.go index d496b6126..85270ce19 100644 --- a/server/model/pipeline.go +++ b/server/model/pipeline.go @@ -61,8 +61,11 @@ func (Pipeline) TableName() string { } type PipelineFilter struct { - Before int64 - After int64 + Before int64 + After int64 + Branch string + Events []WebhookEvent + RefContains string } // IsMultiPipeline checks if step list contain more than one parent step. diff --git a/server/store/datastore/helper.go b/server/store/datastore/helper.go index a883cf516..4ba698b88 100644 --- a/server/store/datastore/helper.go +++ b/server/store/datastore/helper.go @@ -52,7 +52,7 @@ func wrapDelete(c int64, err error) error { } func (s storage) paginate(p *model.ListOptions) *xorm.Session { - if p.All { + if p == nil || p.All { return s.engine.NewSession() } if p.PerPage < 1 { diff --git a/server/store/datastore/pipeline.go b/server/store/datastore/pipeline.go index 41cc1e780..33a68e5bb 100644 --- a/server/store/datastore/pipeline.go +++ b/server/store/datastore/pipeline.go @@ -65,6 +65,18 @@ func (s storage) GetPipelineList(repo *model.Repo, p *model.ListOptions, f *mode if f.Before != 0 { cond = cond.And(builder.Lt{"created": f.Before}) } + + if f.Branch != "" { + cond = cond.And(builder.Eq{"branch": f.Branch}) + } + + if len(f.Events) != 0 { + cond = cond.And(builder.In("event", f.Events)) + } + + if f.RefContains != "" { + cond = cond.And(builder.Like{"ref", f.RefContains}) + } } return pipelines, s.paginate(p).Where(cond). diff --git a/server/store/datastore/pipeline_test.go b/server/store/datastore/pipeline_test.go index 091e44720..fa18a085d 100644 --- a/server/store/datastore/pipeline_test.go +++ b/server/store/datastore/pipeline_test.go @@ -213,21 +213,49 @@ func TestPipelines(t *testing.T) { pipeline1 := &model.Pipeline{ RepoID: repo.ID, Status: model.StatusFailure, + Event: model.EventCron, + Ref: "refs/heads/some-branch", + Branch: "some-branch", } pipeline2 := &model.Pipeline{ RepoID: repo.ID, Status: model.StatusSuccess, + Event: model.EventPull, + Ref: "refs/pull/32", + Branch: "main", } - err1 := store.CreatePipeline(pipeline1, []*model.Step{}...) - g.Assert(err1).IsNil() - err2 := store.CreatePipeline(pipeline2, []*model.Step{}...) - g.Assert(err2).IsNil() - pipelines, err3 := store.GetPipelineList(&model.Repo{ID: 1}, &model.ListOptions{Page: 1, PerPage: 50}, nil) - g.Assert(err3).IsNil() + err := store.CreatePipeline(pipeline1, []*model.Step{}...) + g.Assert(err).IsNil() + err = store.CreatePipeline(pipeline2, []*model.Step{}...) + g.Assert(err).IsNil() + pipelines, err := store.GetPipelineList(&model.Repo{ID: 1}, &model.ListOptions{Page: 1, PerPage: 50}, nil) + g.Assert(err).IsNil() g.Assert(len(pipelines)).Equal(2) g.Assert(pipelines[0].ID).Equal(pipeline2.ID) g.Assert(pipelines[0].RepoID).Equal(pipeline2.RepoID) g.Assert(pipelines[0].Status).Equal(pipeline2.Status) + + pipelines, err = store.GetPipelineList(&model.Repo{ID: 1}, nil, &model.PipelineFilter{ + Branch: "main", + }) + g.Assert(err).IsNil() + g.Assert(len(pipelines)).Equal(1) + g.Assert(pipelines[0].ID).Equal(pipeline2.ID) + + pipelines, err = store.GetPipelineList(&model.Repo{ID: 1}, nil, &model.PipelineFilter{ + Events: []model.WebhookEvent{model.EventCron}, + }) + g.Assert(err).IsNil() + g.Assert(len(pipelines)).Equal(1) + g.Assert(pipelines[0].ID).Equal(pipeline1.ID) + + pipelines, err = store.GetPipelineList(&model.Repo{ID: 1}, nil, &model.PipelineFilter{ + Events: []model.WebhookEvent{model.EventCron, model.EventPull}, + RefContains: "32", + }) + g.Assert(err).IsNil() + g.Assert(len(pipelines)).Equal(1) + g.Assert(pipelines[0].ID).Equal(pipeline2.ID) }) g.It("Should get filtered pipelines", func() { diff --git a/web/src/lib/api/index.ts b/web/src/lib/api/index.ts index a70741901..d355ba0ee 100644 --- a/web/src/lib/api/index.ts +++ b/web/src/lib/api/index.ts @@ -105,7 +105,7 @@ export default class WoodpeckerClient extends ApiClient { async getPipelineList( repoId: number, - opts?: PaginationOptions & { before?: string; after?: string }, + opts?: PaginationOptions & { before?: string; after?: string; ref?: string; branch?: string; events?: string }, ): Promise { const query = encodeQueryString(opts); return this._get(`/api/repos/${repoId}/pipelines?${query}`) as Promise;