woodpecker: Matrix and `when.evaluate` regression (not evaluating matrix variables)
Component
server
Describe the bug
I used to be able to use the following configuration:
matrix:
include:
- TYPE: dev
MAKE_TARGET: build-dev
SSH_TARGET: ssh_target_dev
- TYPE: prod
MAKE_TARGET: build-prod
SSH_TARGET: ssh_target
# Run the correct matrix build on the correct branch
when:
evaluate: |
CI_PIPELINE_EVENT in ["push", "cron", "deployment", "manual"]
and ((CI_COMMIT_BRANCH == CI_REPO_DEFAULT_BRANCH) == ("${TYPE}" == "prod"))
To be able to have a workflow which has 95% overlap between prod and dev, but only runs prod on main and dev on other branches.
When updating to 1.0.0, I noticed that this configuration stopped working.
From the logs, I can see that the filter is evaluated once for the whole workflow, and ${TYPE} is empty/not evaluated. I would expect it to evaluate the filter once for each matrix variant instead, as it used to be ~6 months ago.
System Info
Version: 1.0.0
Run on a NixOS host.
Additional context
Evaluate:\"CI_PIPELINE_EVENT in [\\\"push\\\", \\\"cron\\\", \\\"deployment\\\", \\\"manual\\\"]\\nand ((CI_COMMIT_BRANCH != CI_REPO_DEFAULT_BRANCH) == (\\\"\\\" == \\\"prod\\\"))\\n\"}}}
Validations
- Read the Contributing Guidelines.
- Read the docs.
- Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
- Checked that the bug isn’t fixed in the
nextversion already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use] - Check that this is a concrete bug. For Q&A join our Discord Chat Server or the Matrix room.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 20 (20 by maintainers)
Yes sorry I meant no
teacommand for it.It does have a REST API so
curlis always an option and that was what I had in mind. Thank you for pointing me towards your gitpod setup, that will make it much easier to just copy-paste it! 😃Ah, good to know it’s fixed 😃. I’ll try it when I update the package to the next version and report back if there are issues.
I would just suggest if possible to add a test to ensure this won’t regress in the future? Since there’s no Jsonnet/Starlark configuration (at least without first writing a plug-in etc…) this is probably the easiest way I know to define multiple workflows that have very similar, but slighly different configurations.
Can you add some print statements for debugging?
What I’d like to know: In https://github.com/woodpecker-ci/woodpecker/blob/main/pipeline/frontend/yaml/constraint/constraint.go#L190, print out
env- make sure that there are no secrets or similar things in there when posting.well It’s a regression, but as per label definition: it got released and so it’s a bug