Support "working-directory" input
See original GitHub issueThe 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.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:12
- Comments:7 (2 by maintainers)
Top Results From Across the Web
CmdLine@2 - Command line v2 task - Microsoft Learn
Specifies the working directory to run commands. If you leave it empty, the working directory is $(Build.SourcesDirectory). failOnStderr - Fail ...
Read more >Change current working directory in Azure Pipelines
The answer just highlights that there is a workingDirectory: modifier. At the time of posting this info was really hard to find. –...
Read more >systemd.exec - Freedesktop.org
Takes a directory path relative to the service's root directory specified by RootDirectory= , or the special value " ~ ". Sets the...
Read more >Azure Pipelines Terraform Tasks - Visual Studio Marketplace
The Terraform CLI task support the following Public Cloud providers ... plan' inputs: command: plan workingDirectory: $(test_templates_dir) ...
Read more >Working directory - Wikipedia
In computing, the working directory of a process is a directory of a hierarchical file system, if any, dynamically associated with each process....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Using the
--manifest-path
option to specify theCargo.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?
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 differentbuild.target
than the default, e.g. for embedded software that only builds on a particular architecture.