When triggering a deployment event on an existing pipeline, there is no
way to get the tag used to trigger the parent pipeline, even if this
parent was a tag event.
In our company CI/CD current setup with drone, we use the tag event to
trigger a kaniko image build step, using the git tag as an image tag,
and the deployment/promotion step to effectively deploy this image using
the tag reference in our cluster. This is the only point blocking us to
completely switch to woodpecker and get rid of drone...
What's done:
- changed the metadata environ() method to populate CI_COMMIT_TAG env
var if commit ref starts with /refs/tags (like it's done in drone),
independently of event type EventTag.
Please let me know if I'm wrong, I will happily contribute in this nice
project.
---------
Co-authored-by: Christian Gapany <christian.gapany@netplus.pro>
Co-authored-by: Lauris BH <lauris@nix.lv>
I've tried setting resources for a service and have seen the linter
warning that is not supported, though the the pipeline was successful
and resources were actually set on the pod. So I assume it shouldn't be
a linter issue.
I"m also not sure if my change is correct, I only hope it is
## Some Context
A pipeline example (I've removed steps that are not related directly:
```yaml
---
steps:
test:
name: Test charts
image: quay.io/helmpack/chart-testing
environment:
- DOCKER_HOST=tcp://docker:2375
commands:
- export PATH=$PWD/.bin:$PATH
- apk update && apk add docker
- kind create cluster --config kind.yaml
- sed -i -E -e 's/localhost|0\.0\.0\.0/docker/g' ~/.kube/config
- git fetch origin
- |
if [ -e .changed ]; then
ct install --target-branch main --chart-dirs .
ct install --target-branch main --chart-dirs . --upgrade
fi
services:
docker:
image: docker:dind
commands: dockerd -H tcp://0.0.0.0:2375 --tls=false
privileged: true
ports:
- 2375
backend_options:
kubernetes:
resources:
requests:
memory: 400Mi
cpu: 100m
limits:
memory: 400Mi
cpu: 100m
```
Pod description:
```
Containers:
wp-01hhczdknafj81jv80gzjbgt93-0-services-0:
Limits:
cpu: 100m
memory: 400Mi
Requests:
cpu: 100m
memory: 400Mi
```
Warning in the Woodpecker UI:
```
[linter]woodpecker: services.dockerAdditional property backend_options is not allowed
```
https://go.dev/doc/modules/release-workflow#breaking
Fixes https://github.com/woodpecker-ci/woodpecker/issues/2913 fixes
#2654
```
runephilosof@fedora:~/code/platform-woodpecker/woodpecker-repo-configurator (master)$ go get go.woodpecker-ci.org/woodpecker@v2.0.0
go: go.woodpecker-ci.org/woodpecker@v2.0.0: invalid version: module contains a go.mod file, so module path must match major version ("go.woodpecker-ci.org/woodpecker/v2")
```
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
Add additional string matching to determine when container is not found
or running when invoked via podman compatibility socket
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
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>
if you run woodpecker-agent on windows and connect it to an docker
daemon, there could be two different platforms possible, as you can
switch from linux to windows mode and visa versa
---
*Sponsored by Kithara Software GmbH*
the cmd currently shows the full prompt and drop the exact error level.
this set the prompt to be hidden and let cmd exit with error level
reported by the command
---
*Sponsored by Kithara Software GmbH*
as this secrets have to low entropy they can not be valid secrets and
e.g. make log only unredable
just add a secret with value `a` to a repo an run a pipeline ...
---
*Sponsored by Kithara Software GmbH*
for normal posix shells we have to add the `-e ` option ... but as there
are more shells out there we have to handle this edgecases on base per
base case.
create a switch case statement in woodpecker should be fine as there is
only a finite number of shells, used in production.
also close #2612
---
*Sponsored by Kithara Software GmbH*
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.
- refactor pipeline parsing
- do not parse the pipeline multiple times to perform filter checks, do
this once and perform checks on the result directly
- code deduplication
- refactor forge token refreshing
- move refreshing to a helper func to reduce code
---------
Co-authored-by: Anbraten <anton@ju60.de>
