feat(autodiscovery): add Woodpecker CI plugin#7635
Conversation
|
Hi there!
There are three possible locations for .yaml/.yml files regarding to https://woodpecker-ci.org/docs/usage/workflows |
|
Thanks for pointing that out, @allroundtechie! 🙏 You’re right — Woodpecker workflows can live at:
I’ve updated the PR to explicitly cover |
|
@olblak I don’t have permission to re-run workflows from my fork — could a maintainer re-run the failed job? 🙏 |
|
It looks like the UT are failing. |
|
Thanks! You're right — the UT failure is caused by having both The autodiscovery currently picks one of them (in this case I'll adjust the fixtures/tests to avoid ambiguity by separating the |
Remove duplicate build.yml and update test expectations to use build.yaml
|
Hi @olblak, Thank you for the feedback! Could you please approve the CI workflow to verify the fix? Thank you! |
|
Thanks @railgun-0402 for the pull request |
Fix #7031
What changed
This PR adds Woodpecker CI autodiscovery support by scanning the following file patterns:
.woodpecker/**/*.yml.woodpecker/**/*.yaml.woodpecker.yml.woodpecker.yamlThe crawler parses the Woodpecker pipeline YAML and detects container image references defined via
image:(e.g.registry.service.consul:5000/updatecli:0.111.0).Test
To test this pull request, you can run the following commands:
go test ./...Additional Information
Checklist
repository.
Tradeoff
This implementation focuses on detecting image: fields as plain string values. More advanced cases (templating / anchors / variable interpolation, etc.) are not handled in this PR.
Potential improvement
Extend detection for additional Woodpecker image declaration variants (if any) and add fixtures for nested directories / more complex pipelines.
Consider expanding support for other related fields if Woodpecker introduces alternative image keys in the future.