Currently translated at 100.0% (228 of 228 strings)
Translated using Weblate (Spanish)
Currently translated at 23.2% (53 of 228 strings)
Translated using Weblate (Spanish)
Currently translated at 23.2% (53 of 228 strings)
Co-authored-by: Julio Loayza <julio+woodpecker@loayzameneses.com>
Co-authored-by: Michael <misc+weblatewoodp@zarb.org>
Co-authored-by: Roger Steve Ruiz <roger@0p9.co>
Translate-URL: http://translate.woodpecker-ci.org/projects/woodpecker-ci/ui/es/
Translate-URL: http://translate.woodpecker-ci.org/projects/woodpecker-ci/ui/fr/
Translation: Woodpecker CI/UI
Provide up to date drone compatibility environment variables to each step execution.
closes#1416
Before a step is executed, some environemnt variables are updated.
This ensures, that the updated environment variables are copied to their corresponding `DRONE_` environemt variables.
Side effect is that the `DRONE_` environemnt variables are no longer available in the metadata which should not harm as they are not used inside woodpecker.
As discussed in the comments in PR #1197. Also add documenation
accordingly.
One thing I'm not sure about is the simple check in health.go if the
address is usable in the GET request or not. From reading
https://pkg.go.dev/net#Dial it seems that the only non-standard address
format that would work in the `net` package but not in a GET url would
likely only be `:port`, as the others listed here are actually also
valid urls:
`For TCP, UDP and IP networks, if the host is empty or a literal
unspecified IP address, as in ":80", "0.0.0.0:80" or "[::]:80" for TCP
and UDP, "", "0.0.0.0" or "::" for IP, the local system is assumed.`
One additional thing I noticed is that while `WOODPECKER_SERVER_ADDR`
and `WOODPECKER_SERVER_ADDR` use the default value format of `:PORT`,
`WOODPECKER_SERVER` actually uses `localhost:9000`. I guess it makes a
bit of sense, considering the server might not be local to the agent,
but it looks a bit inconsistent this way. I don't think it would hurt to
make the `WOODPECKER_HEALTHCHECK_ADDR` in this format too, but then it's
different from the server flags again... :-)
closes#1181closes#834
Adds `ignore_failure` to pipeline steps. When it's set to true,
if the step fails the following steps continue to execute as if no failure had occurred.
---
failure enums idea:
* fail (default) = if other steps run in parallel, wait for them and
then let workflow fail
* cancel = if other steps run in parallel, kill them
* ignore = we mark the step as failed but it wont have any impact
This implements #1073, adds .yaml to the accepted endings for woodpecker configs.
This currently adds some more lines to the duplication (tried to compensate by fixing the other duplication in the configFetcher) as the CLI and Server are still separate.
at the moment we compile a script that we can pipe in as single command
this is because of the constrains the docker backend gives us.
so we move it into the docker backend and eventually get rid of it altogether
This PR fixes#1367 with the minimum needed (plus the basics of
annotations and labels, since some clusters need those for extra
verifications, OPA, Kyverno, etc.).
The added role is the minimum access I could get away with (tested each
verb and resource individually), since the Kubernetes go library seems
to use list and get even when not strictly necessary.
I've defaulted to inactive, setting the serviceAccount.rbac.create=true
will create the Role and roleBinding.
The changes only affect the woodpecker-agent chart, as the
woodpecker-server chart currently does nothing directly
# Tests
- [x] non default namespace (roleBindung uses namespace in a not
automatically rewritten position)
- [x] rbac.create enabled and disabled (nothing changes for disabled,
since the templates use a guard)
- [x] custom serviceAccount name
- [x] both roleBinding and role with no annotations, no lables, single
a&l, multiple each
- [x] helm deploy to Kubernetes, with all settings mentioned above
# Documentation
Added in the comments of the values.yaml. Taking it into the docs might
be helpful, but the Kubernetes section in the next docs is fairly empty,
possibly open a new issue and solve when the chart for next is mostly
done.
