The new docs explain how to use the recently introduced kubernetes
backend option to set the security context for pipeline steps.
See #2550
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
Closes#1660
Taken out the part of it that's still up-to-date.
Everything else in this PR is outdated as we don't primarily use quay.io
---------
Co-authored-by: Anbraten <anton@ju60.de>
Co-authored-by: Patrick Schratz <patrick.schratz@gmail.com>
Adds some editorial improvements that hopefully clarify the usage of
secrets.
Fixes#2704
---------
Co-authored-by: Michael Holtermann <michael.holtermann@lynq.tech>
Revert #2180 and #2480 so we can release v2.0 without breaking changes
in pipeline config.
After merging #2476 we should apply these changes to a new v2.
After merging this, we should be ready for the 2.0 release.
---------
Co-authored-by: Anbraten <anton@ju60.de>
implement this fix but with an additional field on workflows to not
change the workflow name
closes#1840closes#713
---------
Co-authored-by: 6543 <6543@obermui.de>
The SSH backend is, similar to Gogs and Coding for forges, completely
unmaintained and seems unused (it is likely broken but we didn't get any
reports).
Instead, you should directly run the agent on the SSH machine with the
`local` backend.
Hi I created a small docs draft adding install instructions for NixOS
since I initially wrote the woodpecker NixOS module which is now in
stable for ~6 months and multiple people my self included actively use
it. cc @ambroisie since we co-maintain it and he did a lot of
improvement work on the module.
CRI-O currently requires some additional config for pipelines to run.
This adds some basic documentation to the kubernetes section explaining
the issue.
See #2510
I had experienced some issues running Woodpecker behind a reverse-proxy,
resulting from not defining the `WOODPECKER_ROOT_PATH` environment
variable in #2477.
As suggested by @qwerty287, specifying `WOODPECKER_ROOT_PATH=/foo`
*mostly* solved the issue of running the woodpecker server at an url
like `https://example.org/foo`.
However, the webhook urls and badge urls were generated excluding the
configured `WOODPECKER_ROOT_PATH`.
This PR (mostly) fixes issues related to non-empty
`WOODPECKER_ROOT_PATH`.
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
- Slimify
- Add required permissions (missing so far)
- More detailed instructions on app settings
- Align env var options to style used in k8s section (UL instead of
headers)
---------
Co-authored-by: Lauris BH <lauris@nix.lv>
The `runs_on` section is missing from the syntax docs. So I added a
section for it, and linked to an example.
It's good enough. But I think it might be a good idea for someone (with
more knowledge than me) to add more info in this section. How to use it,
when to use it, etc. The example is useful but not very informative.
The current documentation mentions that when one uses woodpecker on the
same host as Gitlab, you might need to set the `Allow requests to the
local network from webhooks and integrations` option on the gitlab
server.
This option not only needs to be set when running on the same host, but
also needs to be set when setting up woodpecker with Gitlab on any
RFC1918 net and on any non standard TLD like `.local` or `.internal`.
Dominicandqwerty287
Thomas Anderson
Micashandlnx01
6543andAnbraten
JanikandPatrick Schratz
Michael HoltermannandMichael Holtermann
Martin W. Kirst
Dhadve Yash
Abraham Toriz Cruz
Jacques B
Michalis Zampetakis
Robert Kaussow
Tom Kneiphofandqwerty287
lonix1
LTek-online