Parsing issue when using YAML anchors/aliases for secrets

[lonix1]

Component

server

Describe the bug

As discussed in discord.

There is an issue with how the parser deals with yaml anchors/aliases when used for secrets.

A minimal repro below:

.woodpecker.yml

variables:
  - &USERNAME some_global_secret_1
  - &TOKEN some_global_secret_2

steps:

  use-as-list:
    image: busybox
    commands:
      - echo $USERNAME
      - echo $TOKEN
    secrets:
      - *USERNAME
      - *TOKEN

  use-as-scalar:
    image: woodpeckerci/plugin-docker-buildx
    settings:
      dockerfile: Dockerfile
      registry: ${CI_FORGE_URL##https://}
      username: ${CI_REPO_OWNER}
      password:
        from_secret: *TOKEN
      repo: ${CI_FORGE_URL##https://}/${CI_REPO_OWNER}/myrepo
      tag: test

Dockerfile

FROM busybox
ENTRYPOINT ["echo", "hello"]

Result:

failed to parse pipeline: yaml: unknown anchor 'USERNAME' referenced

@6543 Spent some time investigating. Some preliminary results:

• Test repo here
• Test pipeline here
• Possible issue somewhere here

System Info

1.0.2
docker

Additional context

No response

Validations

• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• [X] Check that this is a concrete bug. For Q&A join our Discord Chat Server or the Matrix room.

[lonix1]

I suspect I found a related issue.

It's slightly different, as above example allows use of an alias as a scalar (from_secret: *TOKEN), whereas below it does not (secrets: *TOKEN). Maybe the schemas as different, and so it's the same bug, I'm unsure.

variables:
  - &TOKEN watchtower_token

steps:

  # other steps...

  deploy:
    image: busybox
    commands:
      - curl -sSf -H "Authorization: Bearer $WATCHTOWER_TOKEN" https://watchtower.example.com/v1/update
   #secrets: ...see various cases below...

Passing case 1: hardcoded literal in list (the only syntax that works)

secrets:
  - watchtower_token

Failing case 1: hardcoded literal

secrets: watchtower_token

failed to parse pipeline: yaml: unmarshal errors: line 1: cannot unmarshal !!str global_... into []*types.Secret

Failing case 2: alias as scalar

secrets: *TOKEN

failed to parse pipeline: yaml: unmarshal errors: line 1: cannot unmarshal !!str global_... into []*types.Secret

Failing case 3: alias in list

secrets:
  - *TOKEN

failed to parse pipeline: yaml: unknown anchor 'TOKEN' referenced

All those cases should be valid yaml.

[qwerty287]

I don't think this is a bug.

All those cases should be valid yaml.

No. We require secrets to be a list, so it can't be a scalar - yes, we added this option to other fields and we could add it for secrets too, but currently, that's not the case and you must use a list.

To use anchors with secrets, the anchor itself must be a list too:

variables:
  - &SECRET [ test_secret ]

...

    secrets: *SECRET

If you have multiple secret anchors, you can combine them like this:

variables:
  - &SECRET [ test_secret ]
  - &SECRET_2 [ test_2 ]

...

    secrets:
      - << *SECRET
      - << *SECRET_2

Both are parsed by woodpecker without errors.

[qwerty287]

Closing for now. If there's still issue, just comment.