diff --git a/README.md b/README.md index 51a5f1713..dd75da51a 100644 --- a/README.md +++ b/README.md @@ -5,8 +5,8 @@
-
-
+
+
@@ -48,92 +48,38 @@ Please consider to donate and become a backer. 🙏 [[Become a backer](https://o
- Pipeline steps can be named as you like
- Run any command in the commands section
-```yaml
-# .woodpecker.yml
-pipeline:
- build:
- image: debian
- commands:
- - echo "This is the build step"
- a-test-step:
- image: debian
- commands:
- - echo "Testing.."
-```
+[Read More](https://woodpecker-ci.org/docs/usage/intro)
### Build steps are containers
- Define any Docker image as context
- Install the needed tools in custom Docker images, use them as context
-```diff
- pipeline:
- build:
-- image: debian
-+ image: mycompany/image-with-awscli
- commands:
- - aws help
-```
+[Read More](https://woodpecker-ci.org/docs/usage/pipeline-syntax#steps)
-### File changes are incremental
+### Plugins
-- Woodpecker clones the source code in the beginning pipeline
-- Changes to files are persisted through steps as the same volume is mounted to all steps
+Woodpecker has [official plugins](https://woodpecker-ci.org/plugins), but you can also use your own.
-```yaml
-# .woodpecker.yml
-pipeline:
- build:
- image: debian
- commands:
- - touch myfile
- 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
-# Dockerfile
-FROM laszlocloud/kubectl
-COPY deploy /usr/local/deploy
-ENTRYPOINT ["/usr/local/deploy"]
-```
-
-```bash
-# deploy
-kubectl apply -f $PLUGIN_TEMPLATE
-```
-
-```yaml
-# .woodpecker.yml
-pipeline:
- deploy-to-k8s:
- image: laszlocloud/my-k8s-plugin
- template: config/k8s/service.yml
-```
+[Read More](https://woodpecker-ci.org/docs/usage/plugins/plugins)
## Documentation
https://woodpecker-ci.org/
-## Who uses Woodpecker?
-
-Currently, I know of one organization using Woodpecker. With 50+ users, 130+ repos and more than 1100 builds a week.
-
-Leave a [comment](https://github.com/woodpecker-ci/woodpecker/issues/122) if you're using it.
-
## Contribution
See [Contributing Guide](CONTRIBUTING.md)
+## Who uses Woodpecker?
+
+[Codeberg](https://codeberg.org), the woodpecker project itself, and many others not listed.
+
+Leave a [comment](https://github.com/woodpecker-ci/woodpecker/issues/122) if you're using it.
+
+## Stars over time
+[](https://starchart.cc/woodpecker-ci/woodpecker)
+
## License
Woodpecker is Apache 2.0 licensed with the source files in this repository having a header indicating which license they are under and what copyrights apply.
diff --git a/docs/docs/20-usage/20-pipeline-syntax.md b/docs/docs/20-usage/20-pipeline-syntax.md
index 7c90a2407..c8853dcba 100644
--- a/docs/docs/20-usage/20-pipeline-syntax.md
+++ b/docs/docs/20-usage/20-pipeline-syntax.md
@@ -24,7 +24,7 @@ In the above example we define two pipeline steps, `frontend` and `backend`. The
## Global Pipeline Conditionals
-Woodpecker gives the ability to skip whole pipelines (not just steps) when based on certain conditions.
+Woodpecker gives the ability to skip whole pipelines (not just steps) when based on certain conditions.
### `branches`
Woodpecker can skip commits based on the target branch. If the branch matches the `branches:` block the pipeline is executed, otherwise it is skipped.
@@ -101,7 +101,7 @@ pipeline:
If required, Woodpecker can be made to skip whole pipelines based on `when`. This could be utilised to ensure compliance that only certain jobs run on certain agents (regional restrictions). Or targeting architectures.
-This is achieved by ensuring the `when` block is on the root level. Rather than
+This is achieved by ensuring the `when` block is on the root level.
See [when](#step-when---step-conditional-execution) above to understand all the different types of conditions that can be used.
@@ -125,12 +125,12 @@ pipeline:
```
-Assuming we have two agents, one `arm` and one `amd64`. Previously this pipeline would have executed on **either agent**, as Woodpecker is not fussy about where it runs the pipelines.
+Assuming we have two agents, one `arm` and one `amd64`. Previously this pipeline would have executed on **either agent**, as Woodpecker is not fussy about where it runs the pipelines.
Because we had our original `when` block underneath the `build` block, if it was run on the `linux/amd64` agent. It would have cloned the repository, and then skipped the build step. Resulting in a Successful build.
Moving the when block to the root level will ensure that the whole pipeline will run be targeted to agents that match all of the conditions.
-This can be utilised in conjunction with other when blocks as well.
+This can be utilised in conjunction with other when blocks as well.
Example `when` pipeline & step block:
@@ -198,6 +198,24 @@ pipeline:
+ - go test
```
+### File changes are incremental
+
+- Woodpecker clones the source code in the beginning pipeline
+- Changes to files are persisted through steps as the same volume is mounted to all steps
+
+```yaml
+# .woodpecker.yml
+pipeline:
+ build:
+ image: debian
+ commands:
+ - echo "test content" > myfile
+ a-test-step:
+ image: debian
+ commands:
+ - cat myfile
+```
+
### `image`
Woodpecker uses Docker images for the build environment, for plugins and for service containers. The image field is exposed in the container blocks in the Yaml:
diff --git a/docs/docs/woodpecker.png b/docs/docs/woodpecker.png
index dde10b80f..b92f3589f 100644
Binary files a/docs/docs/woodpecker.png and b/docs/docs/woodpecker.png differ
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index cf04cf3fe..ac2eebc83 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -100,7 +100,7 @@ module.exports = {
href: 'https://github.com/woodpecker-ci/woodpecker',
},
{
- href: 'https://wp.laszlo.cloud/woodpecker-ci/woodpecker',
+ href: 'https://ci.woodpecker-ci.org/woodpecker-ci/woodpecker',
label: 'CI',
},
],