Support "working-directory" input

[mrowqa]

The action currently assumes there is exactly one Rust project and it's located in the root of the repo. It would be great to support working-directory such as the one you can use with regular run in a workflow step.

[svartalf]

I might miss something here, but would not working-directory just work in this case too?

[mrowqa]

When you define a step, you can use either run or uses. You can specify working-directory only if you choose run - and when you look at the documentation, it's mentioned only there. I tried to use it with uses, but unfortunately after applying some ideas I didn't manage to get it working - sometimes it was ignored, sometimes it caused a workflow format error.

[svartalf]

Ah, yes, you are right, my mistake. It feels, though, that GitHub should support that on a global level, as re-implementing the same thing each time in every Action feels quite redundant.

Maybe it worth to file an issue to GitHub?

[mrowqa]

I see your point. I didn't know where I should file an issue, so I sent an email to [email protected].

[mbStavola]

It's really unfortunate that Github Actions doesn't support working-dir in a use context, huge oversight! Hopefully they can address it soon.

While they work on that though, for anyone who is having trouble using this Action because of that limitation, this might help:

clippy:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v1
    - run: rustup component add clippy
    - uses: actions-rs/clippy-check@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        args: --all-features --manifest-path path/to/Cargo.toml

--manifest-path allows you to essentially set the working dir of the crate, since it seems like the Clippy action runs relative to wherever the specified Cargo.toml lives.

[dmontagu]

Using the --manifest-path option to specify the Cargo.toml file seems to ensure the action works, but it doesn't seem to get the paths right (they are relative to where Cargo.toml lives, not the repository root), so the feedback can't be viewed from the files view of the PR. (Though they it does appear in the checks list.)

Any suggestions for a workaround?

[qwandor]

The problem with the --manifest-path approach is that it doesn't use the .cargo/config under the crate directory. This may be a problem if it specifies a different build.target than the default, e.g. for embedded software that only builds on a particular architecture.