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

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 20 (20 by maintainers)

Commits related to this issue

Most upvoted comments

Yes sorry I meant no tea command for it.

It does have a REST API so curl is 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