Support changing working directory

[jgrund]

So cargo commands can be run in subdirectories.

[svartalf]

Sounds like a good idea to add, smth like

- uses: actions-rs/cargo@v1
  with:
    cwd: ./sub-folder
    command: build

I'll try to add it tomorrow

[svartalf]

Btw, @jgrund, can you elaborate a little bit on your case? Do you have a cargo workspace or rust project is just laying in a sub-folder of repository root?

[jgrund]

I have a top-level workspace, and then a workspace in a subfolder within the same project.

The workspaces are not tied together by cargo (one is backend code, one is wasm front-end code), so I can't use cargo -p from the top level.

[svartalf]

@jgrund I researched it for a bit and found the working-directory parameter for steps, that should do the job for your case.

[Arnavion]

working-directory appears to only work for the run action (which your docs link is for), not for arbitrary actions like actions-rs/cargo

[nelsonjchen]

Here's an example of working-directory not working for non-run actions:

https://github.com/nelsonjchen/com-rs/commit/c3af52907da12cb4331c17a48e84f4a6a52afa0c/checks?check_suite_id=366094450

Could this issue be reopened?

[Arnavion]

@nelsonjchen You should be able to do:

command: build
args: --manifest-path examples/aggregation/Cargo.toml

... instead of needing to change the working directory.

(Edit: Fixed suggestion as nelsonjchen pointed out.)

[nelsonjchen]

@Arnavion I had to use args: (only build is accepted in command:) but otherwise yeah, that works for me.

nelsonjchen/com-rs@0b6f041

Thanks!

[dbrgn]

I also ran into this issue. A proper working-directory argument would be nice, even though the workaround seems to work.

[Xcodo]

This tripped me up a bit today too. working_directory would be clearer than using --manifest-path for me.

[teburd]

I ran into this today myself while working on using actions for CI on a complex workspace.

I would much prefer working_directory here.

[mtslzr]

Chiming in with another +1. While the work-around works... the purpose of using a package it to have the workflow be more elegant. Adding support for working-directory is definitely preferred.

[MarcoPolo]

The workaround doesn't seem to work with cross.

Specifically I'm doing:

      - uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          target: x86_64-unknown-linux-musl
          override: true
      - uses: actions-rs/cargo@v1
        with:
          use-cross: true
          command: build
          args: --release --target=x86_64-unknown-linux-musl --manifest-path hello-lambda/Cargo.toml

And it fails in an error about musl-gcc.

[MarcoPolo]

As a workaround you can use my fork like so:

...
      - uses: marcopolo/cargo@master
        with:
          command: build
          working-directory: YOUR_SUBDIRECTORY

I added a PR here: #59

[svartalf]

@MarcoPolo does your change works correctly with cross enabled?

[MarcoPolo]

Yes

[adamgreig]

Just to chime in with another use case for working_directory that --manifest-path doesn't cover: if you have a .cargo/config in the directory you want to build in, it's not picked up when using --manifest-path.

My repo has an embedded project in /firmware/ where .cargo/config sets the target and some rustc flags for linker scripts, so it's quite a pain to specify them as extra args to cargo, but a working_directory setting would do the trick nicely.

[tarcieri]

FYI, we're also using @MarcoPolo's fork in conjunction with use_cross: true successfully:

RustCrypto/asm-hashes#20

It'd sure be nice if #59 got merged!

[boaz-codota]

This is still something that will help greatly at 2021. @svartalf possible to merge the PR or add the existing way to the docs?

[pfmooney]

Just to chime in with another use case for working_directory that --manifest-path doesn't cover: if you have a .cargo/config in the directory you want to build in, it's not picked up when using --manifest-path.

My repo has an embedded project in /firmware/ where .cargo/config sets the target and some rustc flags for linker scripts, so it's quite a pain to specify them as extra args to cargo, but a working_directory setting would do the trick nicely.

Changing the working directory would also mean picking up any rust-toolchain specified there - a definite nice-to-have.

[lovasoa]

Hello ! I am affected by this too. Could this issue be reopened ?

[jblachly]

@nelsonjchen You should be able to do:

command: build
args: --manifest-path examples/aggregation/Cargo.toml

... instead of needing to change the working directory.

(Edit: Fixed suggestion as nelsonjchen pointed out.)

This is not a suitable replacement, as the cwd as the rust binary sees it is the root; resources like .env files, static assets etc. are typically specified relative to the crate root, not the monorepo (or whatever) root

[sam0x17]

I am unable to use actions-rs actions on my project because of this issue and am instead manually installing cargo in a GitHub Action.

[danielhenrymantilla]

Also noting that an actual cd is needed not only for rust-toolchain files, but also .cargo/config files: --manifest-path is thus not equivalent.