Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Folded chomping block parse error #418

Closed
crawford opened this issue Apr 9, 2020 · 5 comments
Closed

Folded chomping block parse error #418

crawford opened this issue Apr 9, 2020 · 5 comments
Labels
bug Something isn't working

Comments

@crawford
Copy link

crawford commented Apr 9, 2020

Describe the bug
When using a folded chomping block (>-) to specify the run command, it seems as though only the first line gets executed.

To Reproduce
Create a workflow like the following:

name: example
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: >-
          cargo test
            --verbose

Expected behavior
cargo test --verbose should be invoked.

Runner Version and Platform

Version of your runner? 2.168.0

OS of the machine running the runner? Ubuntu 18.04.4 LTS

What's not working?

It appears as though only cargo test is being invoked. The output of the step is not the verbose output of cargo.

Notes

The using an indent block works as expected, though I don't like needing to use shell escapes inside of YAML:

name: example
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: |
          cargo test \
            --verbose
@crawford crawford added the bug Something isn't working label Apr 9, 2020
crawford added a commit to crawford/efm32gg-hal that referenced this issue Apr 9, 2020
This introduces two workflows: one for basic CI (format and check) and
one for security audits. The security audit workflow probably isn't
going to catch anything, but it only runs when the cargo manifest
changes, so hopefully it doesn't slow things down too much. The CI
workflow is designed to run `cargo fmt` against the code and to run
`cargo check` with every combination of options. Right now, the
`unproven` feature must be enabled, which ends up requiring a nightly
compiler. As a result, the build matrix only runs two variants (one for
each of the two supported devices). Once builds can be done without the
`unproven` feature, `~` can be added to the `proven` dimension of the
matrix, which will then allow builds to run against both nightly and
stable.

Regarding the actual implementation, there are a few quirks in this
config.

The verbose `on` object is the result of pushes to pull requests
triggering the workflow twice - the workflow is triggerd by both the
`push` and `pull_request` events. By restricting these to the master
branch, it ensures that only pushes to the master branch or pull
requests to the master branch (but not pushes to pull request branches)
trigger.

The bizarre construction of the `run` step in the `check` job is needed
because GitHub isn't parsing the declaration correctly [1]. The
preferred syntax would be to make use of the folded chomping block
operator and to drop the shell linewraps. Something closer to this:

```yaml
steps:
  - run: >-
      cargo check
        --verbose
        --no-default-features
```

[1]: actions/runner#418
crawford added a commit to crawford/efm32gg-hal that referenced this issue Apr 9, 2020
This introduces two workflows: one for basic CI (format and check) and
one for security audits. The security audit workflow probably isn't
going to catch anything, but it only runs when the cargo manifest
changes, so hopefully it doesn't slow things down too much. The CI
workflow is designed to run `cargo fmt` against the code and to run
`cargo check` with every combination of options. Right now, the
`unproven` feature must be enabled, which ends up requiring a nightly
compiler. As a result, the build matrix only runs two variants (one for
each of the two supported devices). Once builds can be done without the
`unproven` feature, `~` can be added to the `proven` dimension of the
matrix, which will then allow builds to run against both nightly and
stable.

Regarding the actual implementation, there are a few quirks in this
config.

The verbose `on` object is the result of pushes to pull requests
triggering the workflow twice - the workflow is triggerd by both the
`push` and `pull_request` events. By restricting these to the master
branch, it ensures that only pushes to the master branch or pull
requests to the master branch (but not pushes to pull request branches)
trigger.

The bizarre construction of the `run` step in the `check` job is needed
because GitHub isn't parsing the declaration correctly [1]. The
preferred syntax would be to make use of the folded chomping block
operator and to drop the shell linewraps. Something closer to this:

```yaml
steps:
  - run: >-
      cargo check
        --verbose
        --no-default-features
```

[1]: actions/runner#418
@TingluoHuang
Copy link
Member

@crawford we don't support >- in workflow YAML. We only used a subset of YAML feature in the workflow.

@crawford
Copy link
Author

@TingluoHuang are the supported language features documented anywhere?

@TingluoHuang
Copy link
Member

@crawford sorry I couldn't find any better doc, but anything that not listed in this doc is definitely not supported. 😞

@TingluoHuang
Copy link
Member

Closing this for now since this is not supported.

@rhysd
Copy link

rhysd commented Feb 20, 2024

I think GitHub Actions runtime is working correctly here.

>-
  cargo test
    --verbose

is parsed as the following string conforming the YAML specification.

"cargo test\n  --verbose"

You should not add extra indent. What you wanted is probably

>-
  cargo test
  --verbose

This is parsed as

"cargo test --verbose"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants