actions-rs / cargo Goto Github PK

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

This action runs cargo with arguments. When cargo finds problems they are annotated in a way GitHub can display them at the exact file / line.

When --color=always is added this doesn't work anymore.

You can reproduce this by creating some issue which cargo highlights. This works properly. When --color=always is added the output reduces to "[…] failed with exit code 101".

Workflow code

      - name: Check clippy
        uses: actions-rs/cargo@v1
        with:
          command: clippy
-          args: --verbose --locked --all-targets ${{ matrix.features }} -- ${{ matrix.clippyargs }}
+          args: --verbose --locked --all-targets ${{ matrix.features }} --color=always -- ${{ matrix.clippyargs }}

Action output

works

https://github.com/EdJoPaTo/rust-binary-metafile-template/actions/runs/1399909575

works.zip

doesn't work

https://github.com/EdJoPaTo/rust-binary-metafile-template/actions/runs/1399969307

doesnt-work.zip

Expected behavior

Described above

Additional context

--color=always is probably not working because of additional escape codes in the output.

Personal opinion: I do not think its interesting to support color output. I think outputting a warning when --color is specified is helpful to prevent people from running into this issue.

My workflow seems to successfully build but I do not know where the build artefacts are. I tried doing a find \ but it didn't find anything.

How do I determine the location of the compiled binary and man files?

jobs:
  armv7l:
    name: armv7l build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          repository: ogham/exa
      - uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          target: armv7-unknown-linux-gnueabihf
          override: true
      - uses: actions-rs/cargo@v1
        with:
          use-cross: true
          command: build

Dependabot couldn't authenticate with npm.pkg.github.com.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

You can mention @dependabot in the comments below to contact the Dependabot team.

So cargo commands can be run in subdirectories.

How do I save the output of a cargo command to file in a Github action?

Specifically, I want to do something like:

cargo build --message-format json > build.log to save a log of the build in my CI.

Great work on actions-rs so far! 😄

Here is an example of the failure: https://github.com/matchai/test-rust-actions/runs/222483203
The same run contains a Linux build that runs successfully.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

I'm currently using github actions to test-build my project with for x86_64. I'd like to extend this to other architectures, and there's an example in the README on how to do that. I've tried to use that for my project, but then noticed the build fails my project depends on additional libaries that are missing in the cross build container. This is related to cross-rs/cross#149 but it's unclear how to use the hacks mentioned in the issue with github actions.

Workflow example

I don't know what's the best way to integrate this, and I assume it'd need proper support by cross.

on: [push]

name: ARMv7 build

jobs:
  linux_arm7:
    name: Linux ARMv7
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          target: armv7-unknown-linux-gnueabihf
          override: true
      # prepare container image somehow
      - uses: actions-rs/cargo@v1
        with:
          apt:
          - libpcap-dev
          - libseccomp-dev
      - uses: actions-rs/cargo@v1
        with:
          use-cross: true
          command: build
          args: --target armv7-unknown-linux-gnueabihf

Additional context

I wrote this script in an attempt to apply the workarounds mentioned in the cross issue tracker, but couldn't get it to work because I need to have the cross binary in advance to detect the version for the image I'm preparing (therefore this is all untested):

#!/bin/sh
set -xe

case "$1" in
    arm-*)
        ARCH=arm64
        ;;
    armv7-*)
        ARCH=arm64
        ;;
    aarch64-*)
        ARCH=arm64
        ;;
    i686-*)
        ARCH=i386
        ;;
    *)
        echo 'ERROR: unknown arch'
        exit 1
        ;;
esac

CROSS=`cross -V | sed -nr 's/cross (.*)/\1/p'`

cat > Dockerfile.cross <<EOF
FROM rustembedded/cross:$1-$CROSS
RUN dpkg --add-architecture $ARCH && \
    apt-get update && \
    apt-get install libpcap-dev:$ARCH libseccomp-dev:$ARCH
EOF

docker build -t "rustembedded/cross:$1-$CROSS" Dockerfile.cross

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

nice-to-have feature request: instead of having to look through job logs, the cargo action would show warnings and errors from cargo directly in the PR file view.

For example, to show an error in the file view in shell:

echo "::error file=src/lib.rs,line=30,endLine=30::`#![feature]` may not be used on the stable release channel"

Workflow example

No change in workflow files, the typical use of this action would Just Work:

on: [push]

name: CI

jobs:
  build_and_test:
    name: Rust project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
      - uses: actions-rs/cargo@v1
        with:
          command: build
          args: --release --all-features

Additional context

See https://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions

I'm not willing to work on this at the moment and just wanted to hear your thoughts about this feature.

Description

reported initially here:
uutils/coreutils#3210

Using use-cross on an Ubuntu 18.04 fails with:

/home/runner/.cargo/bin/cross build --release --target=x86_64-unknown-linux-musl --features feat_os_unix_musl
/home/runner/.cargo/bin/cross: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /home/runner/.cargo/bin/cross)
/home/runner/.cargo/bin/cross: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/runner/.cargo/bin/cross)

Seems that bin/cross is built on more recent ubuntu.

Workflow code

with:
  use-cross: true
  command: build
  args: --release --target=i686-unknown-linux-gnu  --features "feat_os_unix"

Action output

Full log
https://pipelines.actions.githubusercontent.com/Tv5Yv5nIzIhWaMo3xdKzjIorSSIlfCwnxr6L52Y7lKBOTZPJ76/_apis/pipelines/1/runs/11115/signedlogcontent/108?urlExpires=2022-03-04T09%3A13%3A09.6744026Z&urlSigningMethod=HMACV1&urlSignature=xSNv6KgC1Ad9w1%2BNkNhLIfRY2lnHlBJl4l0V8SHHrpA%3D

2022-03-03T23:56:20.0182827Z ##[group]Run actions-rs/cargo@v1
2022-03-03T23:56:20.0183065Z with:
2022-03-03T23:56:20.0183223Z   use-cross: true
2022-03-03T23:56:20.0183409Z   command: build
2022-03-03T23:56:20.0183676Z   args: --release --target=i686-unknown-linux-gnu  --features "feat_os_unix"
2022-03-03T23:56:20.0183926Z env:
2022-03-03T23:56:20.0184091Z   PROJECT_NAME: coreutils
2022-03-03T23:56:20.0184342Z   PROJECT_DESC: Core universal (cross-platform) utilities
2022-03-03T23:56:20.0184579Z   PROJECT_AUTH: uutils
2022-03-03T23:56:20.0184757Z   RUST_MIN_SRV: 1.54.0
2022-03-03T23:56:20.0184953Z   STYLE_FAIL_ON_FAULT: true
2022-03-03T23:56:20.0185318Z   CACHE_ON_FAILURE: false
2022-03-03T23:56:20.0185494Z   CARGO_INCREMENTAL: 0
2022-03-03T23:56:20.0185675Z ##[endgroup]
2022-03-03T23:56:20.1174653Z [command]/home/runner/.cargo/bin/cross build --release --target=i686-unknown-linux-gnu --features feat_os_unix
2022-03-03T23:56:20.1251071Z /home/runner/.cargo/bin/cross: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /home/runner/.cargo/bin/cross)
2022-03-03T23:56:20.1253486Z /home/runner/.cargo/bin/cross: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/runner/.cargo/bin/cross)
2022-03-03T23:56:20.1293264Z ##[error]The process '/home/runner/.cargo/bin/cross' failed with exit code 1

Maybe caused by rust-lang/rust#90846 ?!

Description

Workflow code

https://github.com/NPC-Studio/yy-boss/blob/master/.github/workflows/main.yml

(this is just the quickstart action without Clippy)

Action output

failed to get `yy-typings` as a dependency of package `yy-boss v0.1.1 (/home/runner/work/yy-boss/yy-boss)`

Expected behavior

see below

Additional context

This isn't really a bug, but a request for some guidance on a particular issue with Cargo. I hope this is a good place to ask!
So the issue is because my Cargo.toml in that project has the following dependency:

yy-typings = { path = "../yy-typings", version = "0.1" }

This is because I develop this other crate, generally, at the same time, so it just makes sense to have a local path dependency on my local.

Is there some way to get the action to only build using the Crates.io referenced there? Right now, it builds on every push, but in the future, it will only build on tagged commits, so I will know that the crates.io version will be up to date.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

First, thanks for creating these actions, super helpful!

In my project, I have a couple of rust files which are there as test resources, however, I want them to be automatically checked by cargo fmt as well. Since they are not attached to any project, I need to pass the file paths directly to rustfmt.

cargo fmt -- tests/resources/**/*.rs --check works perfectly fine from my shell but it appears that this action does not expand glob patterns, which causes the following action to fail.

Workflow code

      - name: Run cargo fmt on tests resources
        uses: actions-rs/cargo@v1
        with:
          command: fmt
          args: -- tests/resources/**/*.rs --check

Action output

Run actions-rs/cargo@v1
/home/runner/.cargo/bin/cargo fmt -- tests/resources/**/*.rs --check
Error: file `tests/resources/**/*.rs` does not exist
Error: The process '/home/runner/.cargo/bin/cargo' failed with exit code 1

Expected behavior

Glob patterns are expanded and the action checks all files.

Additional context

I found a way around it:

      - name: Gather test resources
        run: echo "TEST_RESOURCES_RUST=$(ls tests/resources/**/*.rs | tr '\n' ' ')" >> $GITHUB_ENV

      - name: Run cargo fmt on tests resources
        uses: actions-rs/cargo@v1
        with:
          command: fmt
          args: -- ${{ env.TEST_RESOURCES_RUST }} --check

cargo mutants is a cargo plugin that finds insufficiently tested code.

It can be run from CI as in https://github.com/sourcefrog/cargo-mutants#continuous-integration, for example as in https://github.com/sourcefrog/unix_mode/runs/7303576645?check_suite_focus=true.

Would it be acceptable in principle to add this in to actions-rs?

cc sourcefrog/cargo-mutants#37 @sgodwincs

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

It would be nice to be able to capture stdout / stderr on certain commands. My example: I have a workflow which runs a script using cargo make the output of which I'd like to capture and put in a comment on PRs. See here:

https://github.com/arlyon/async-stripe/blob/master/.github/workflows/openapi.yml#L27-L32

The missing part is that outputs.stdout is not actually populated with anything yet.

Workflow example

No proposed changes to the workflow definitions, just populate the stdout / stderr outputs for use in other actions.

Additional context

The run command allows you to do this just fine, but I'd like to use the dedicated action if possible, rather than manually calling cargo make verify.

rustfmt messages usually starts with line similar to this:

Diff in /home/runner/some/random/path.rs at line 135:

We could probably add the problem matcher similar to rust one to highlight them, so it would be easier to read logs.

Thing to check: would it be possible to "enable" this matcher only if cargo fmt* program is called?

https://code.visualstudio.com/docs/editor/tasks#_defining-a-problem-matcher

This is my first time trying GitHub Actions, so apologies for the basic question.

I see that the example workflow in this repo's readme contains this example step:

- uses: actions-rs/cargo@v1
  with:
    command: build
    args: --release --all-features

Based on the readme of this repo it wasn't clear to me what benefit this would have over just:

- run: cargo build --release --all-features

which appears to work.

Maybe the readme could emphasize some of the benefits?

Thanks!

Using sccache will dramatically speedup compilation time in large projects.

Description

The actions-rs/cargo@v1 does not pass environment variables such as RUSTFLAGS to cargo.

Workflow code

Workflow

Action output

In this job run:

2020-06-05T14:50:25.2752491Z ##[group]Run actions-rs/cargo@v1
2020-06-05T14:50:25.2752621Z with:
2020-06-05T14:50:25.2752725Z   use-cross: true
2020-06-05T14:50:25.2752840Z   command: build
2020-06-05T14:50:25.2752987Z   args: --manifest-path jormungandr/Cargo.toml
--bin jormungandr
--no-default-features
--verbose
--locked
--release
--target aarch64-linux-android

2020-06-05T14:50:25.2753137Z env:
2020-06-05T14:50:25.2753250Z   DATE: 20200605
2020-06-05T14:50:25.2753493Z   RUSTFLAGS: -C target-cpu=generic -C lto
2020-06-05T14:50:25.2753613Z ##[endgroup]

The effect of RUSTFLAGS is not seen in the compiler invocations:

2020-06-05T15:02:11.6410263Z      Running `rustc --crate-name multiaddr /cargo/registry/src/github.com-1ecc6299db9ec823/multiaddr-0.3.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C metadata=1508ab820d2f6caf -C extra-filename=-1508ab820d2f6caf --out-dir /target/aarch64-linux-android/release/deps --target aarch64-linux-android -C linker=aarch64-linux-android-gcc -L dependency=/target/aarch64-linux-android/release/deps -L dependency=/target/release/deps --extern byteorder=/target/aarch64-linux-android/release/deps/libbyteorder-c7da6d79ae555619.rmeta --extern cid=/target/aarch64-linux-android/release/deps/libcid-05098fa37c1387c6.rmeta --extern integer_encoding=/target/aarch64-linux-android/release

A sister job without cross compiles with the passed options.

Expected behavior

RUSTFLAGS and other environment variables should be consistently passed down to cargo and any build scripts that may make use of them.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Attempting to setup automated cargo publishing for our repo (https://github.com/railwayapp/nixpacks/).

Added actions-rs/cargo but keep getting this error

https://github.com/railwayapp/nixpacks/runs/8280426557?check_suite_focus=true

Expected behavior

Should be able to just call cargo release <patch|minor|major> --execute and have it work

Additional context

Add any other context about the problem here.

When trying to use cargo login in preparation of publishing to crates.io the token is not passed a cargo login argument and then the command hangs indefinitely waiting for input.

Example task:

- name: Login to crates.io
  uses: actions-rs/cargo@v1
  with:
    toolchain: nightly
    command: login
    arguments: ${{ secrets.CRATES_TOKEN }}

I'm new to GitHub actions so I'm not sure if maybe I'm misusing this and I need to pass the argument in another way.

Description

I've been attempting to cross compile a Rust project for i686-pc-windows-gnu on the ubuntu-latest platform, which appears to work fine until the linking stage. Related PR is here: FrancisRussell/zoog#17

Workflow code

https://github.com/FrancisRussell/zoog/blob/3dbd3d39438db55344819d9df067490073a93a35/.github/workflows/ci.yml

Action output

2021-01-03T20:43:56.9218892Z    Compiling rand_chacha v0.2.2
2021-01-03T20:43:58.6301048Z    Compiling rand v0.7.3
2021-01-03T20:44:00.8677438Z    Compiling term_size v0.3.2
2021-01-03T20:44:01.1447605Z    Compiling remove_dir_all v0.5.3
2021-01-03T20:44:01.7061525Z    Compiling textwrap v0.11.0
2021-01-03T20:44:02.4005338Z    Compiling tempfile v3.1.0
2021-01-03T20:44:03.2505163Z    Compiling clap v2.33.3
2021-01-03T20:44:06.9047767Z    Compiling thiserror-impl v1.0.23
2021-01-03T20:44:09.9889944Z    Compiling derivative v2.1.1
2021-01-03T20:44:15.0369777Z    Compiling thiserror v1.0.23
2021-01-03T20:44:15.1810628Z    Compiling zoog v0.1.1 (/home/runner/work/zoog/zoog)
2021-01-03T20:44:16.7638877Z error: linker `i686-w64-mingw32-gcc` not found
2021-01-03T20:44:16.7646309Z ##[error]  |
2021-01-03T20:44:16.7664285Z   = note: No such file or directory (os error 2)
2021-01-03T20:44:16.7664667Z 
2021-01-03T20:44:16.7665437Z error: aborting due to previous error
2021-01-03T20:44:16.7666432Z ##[error]aborting due to previous error
2021-01-03T20:44:16.7813670Z error: could not compile `zoog`
2021-01-03T20:44:16.7814617Z ##[error]could not compile `zoog`
2021-01-03T20:44:16.7816604Z To learn more, run the command again with --verbose.
2021-01-03T20:44:16.7819154Z ##[error]The process 'cross' failed with exit code 101

Expected behavior

Compilation succeeds.

Additional context

From what I can tell, cross does support this target which is why I'm filing here first.

cargo-release is pretty awesome, and it seems github actions would be perfect to build releases across multiple operating systems.

Can we bake cargo-release into this workflow, or provide a way to use it?

now i want to compile aarch64-pc-windows-msvc on windows now in github action.

# windows
          - target: x86_64-pc-windows-msvc
            release-name: x86_64-windows
            suffix: .exe
            use-cross: false

          - os: windows-latest
            target: aarch64-pc-windows-msvc
            suffix: .exe
            use-cross: true

x86_64 is successed but aarch failed because of

the link is modified: .github/workflows/release.yml
how can i do?

At https://github.com/step-security/secure-workflows we are building a knowledge-base (KB) of GITHUB_TOKEN permissions needed by different GitHub Actions. When developers try to set minimum token permissions for their workflows, they can use this knowledge-base instead of trying to research permissions needed by each GitHub Action they use.

Below you can see the KB of your GITHUB Action.

name: 'rust-cargo' # actions-rs/cargo
# GITHUB_TOKEN not used

If you think this information is not accurate, or if in the future your GitHub Action starts using a different set of permissions, please create an issue at https://github.com/step-security/secure-workflows/issues to let us know.

This issue is automatically created by our analysis bot, feel free to close after reading :)

References:

GitHub asks users to define workflow permissions, see https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ and https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token for securing GitHub workflows against supply-chain attacks.

Setting minimum token permissions is also checked for by Open Source Security Foundation (OpenSSF) Scorecards. Scorecards recommend using https://github.com/step-security/secure-workflows so developers can fix this issue in an easier manner.

error: `core::slice::<impl [T]>::len` is not yet stable as a const fn
##[error]   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-0.5.2/src/bytes.rs:121:18

Is 1.39 supported or is this an unreleated error?

As the cross = "0.1.15" seems to be broken (ex. cross-rs/cross#306, cross-rs/cross#319), specific Git revision of it used to install. Obviously, it is not a desired result, so it should be handled later.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Ubuntu builds succeed, but the same step definition for runs-on: macOS-latest is unable to find cargo?:

Run actions-rs/[email protected]
Install cross
cross build --target x86_64-unknown-linux-musl --all-features --verbose
+ "cargo" "build" "--target" "x86_64-unknown-linux-musl" "--all-features" "--verbose"
error: could not find `Cargo.toml` in `/Users/runner/work/rust-htslib/rust-htslib` or any parent directory
Error: The process 'cross' failed with exit code 101

Workflow code

  Testing-OSX:
    needs: Formatting
    runs-on: macOS-latest
    steps:
      - name: Test musl build with all features and debug symbols (non --release) on OSX
        uses: actions-rs/[email protected]
        with:
          use-cross: true
          command: build
          args: --target x86_64-unknown-linux-musl --all-features --verbose

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

include_bytes! does not find a valid and existing file in the project directory

Workflow code

on: [push, pull_request]
name: xcompile
env:
  PKG_CONFIG_PATH: "/usr/lib/x86_64-linux-gnu/pkgconfig"

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    strategy:
      matrix:
        target:
          # - aarch64-apple-darwin
          # - x86_64-unknown-linux-gnu
          - x86_64-pc-windows-gnu
        cross: [true]
    steps:
      - uses: actions/checkout@v3
      - name: Check if BQN.Wasm exists
        run: file /home/runner/work/beacon/beacon/src/BQN.wasm
      - name: Toolchain
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          target: ${{ matrix.target }}
          override: true
      - name: Install dependencies
        run: |
          sudo apt-get install cmake pkg-config libfreetype6-dev fontconfig libfontconfig libfontconfig1-dev libxcb-xfixes0-dev libxkbcommon-dev
      - if: ${{ matrix.cross }}
        name: Create Cross.toml
        shell: bash
        run: |
          cat > Cross.toml <<EOF
          [build.env]
          passthrough = ["BQN_WASM"]
          EOF
      - name: Cargo Build
        uses: actions-rs/cargo@v1
        env:
          BQN_WASM: /home/runner/work/beacon/beacon/src/BQN.wasm
        with:
          use-cross: true
          command: build
          args: --release --target=${{ matrix.target }} --no-default-features --features=bqnwasm
      - name: Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: |
            README.md
            LICENSE

Action output

Expected behavior

BQN.wasm should have been found. It works locally.

Additional context

For debugging purposes I added a step that checked the existence of the wasm file, with the following command: file /home/runner/work/beacon/beacon/src/BQN.wasm and the output of that step is:

Run file /home/runner/work/beacon/beacon/src/BQN.wasm
/home/runner/work/beacon/beacon/src/BQN.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)

But later in the build step, cargo is unable find the same file

error: couldn't read /home/runner/work/beacon/beacon/src/BQN.wasm: No such file or directory (os error 2)

Error:   --> /cargo/registry/src/index.crates.io-6f17d22bba15001f/cbqn-0.1.0/src/backend/wasi.rs:94:36
   |
94 | static WASM_BYTES: &'static [u8] = include_bytes!(env!("BQN_WASM"));
   |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Hi, I'm creating this issue because i've spend a couple of DAYS trying to solve the following problem but no success.
I got a rust web server which has the following dependency openssl = { version = "=0.10.45", features = ["vendored"] } which is fails to compile when i use cross in Github Action. Previously it was working, but as i understand there is no longer support of openssl in cross so it is just started to fail. I've tried to install openssl, it is present in a system but during compilation i got the following error:

error: failed to run custom build command for `sasl2-sys v0.1.20+2.1.28`

Caused by:
  process didn't exit successfully: `/target/release/build/sasl2-sys-f091b2042744285f/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=SASL2_STATIC
  cargo:rerun-if-env-changed=LIBSASL2_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

--- stderr
  thread 'main' panicked at 'Unable to find libsasl2 on your system. Hints:

    * Have you installed the libsasl2 development package for your platform?
      On Debian-based systems, try libsasl2-dev. On RHEL-based systems, try
      cyrus-sasl-devel. On macOS with Homebrew, try cyrus-sasl.

    * Have you incorrectly set the SASL2_STATIC environment variable when your
      system only supports dynamic linking?

    * Are you willing to enable the `vendored` feature to instead build and link
      against a bundled copy of libsasl2?
  ', /cargo/registry/src/github.com-1ecc6299db9ec823/sasl2-sys-0.1.20+2.1.28/build.rs:342:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Looking for help and suggestions for this, thank you very much

Workflow code

This is my pipeline which was working previously:

...
jobs:
  build:
    name: Build for Raspberry PI
    runs-on: ubuntu-20.04

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2
        with:
          submodules: recursive

      - uses: actions-rs/toolchain@v1
        with:
          toolchain: 1.62.1-x86_64-unknown-linux-gnu
          target: aarch64-unknown-linux-gnu
          override: true

      - uses: actions-rs/cargo@v1
        with:
          use-cross: true
          command: build
          args: --release --target aarch64-unknown-linux-gnu
...

Action output

error: failed to run custom build command for `sasl2-sys v0.1.20+2.1.28`

Caused by:
  process didn't exit successfully: `/target/release/build/sasl2-sys-f091b2042744285f/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=SASL2_STATIC
  cargo:rerun-if-env-changed=LIBSASL2_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

--- stderr
  thread 'main' panicked at 'Unable to find libsasl2 on your system. Hints:

    * Have you installed the libsasl2 development package for your platform?
      On Debian-based systems, try libsasl2-dev. On RHEL-based systems, try
      cyrus-sasl-devel. On macOS with Homebrew, try cyrus-sasl.

    * Have you incorrectly set the SASL2_STATIC environment variable when your
      system only supports dynamic linking?

    * Are you willing to enable the `vendored` feature to instead build and link
      against a bundled copy of libsasl2?
  ', /cargo/registry/src/github.com-1ecc6299db9ec823/sasl2-sys-0.1.20+2.1.28/build.rs:342:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior

Should be able to cross compile to specified target especially when openssl is set as vendored

Additional context

I had another pipeline which doesn't compile due to openssl but it is not cross compiling to another target and it was fixed just but adding those suggested commands.

I've tried adding following configuration but doesn't matter what i do openssl package can't detect openssl on a system

sudo apt install libssl-dev libsasl2-dev
touch $HOME/.cargo/config && cd $HOME/.cargo
echo [target.aarch64-unknown-linux-gnu] >> ./config
echo pre-build = [\"sudo apt install libssl-dev libsasl2-dev\"] >> ./config

and

sudo dpkg --add-architecture arm64
sudo apt-get update && sudo apt install libssl-dev libssl-dev:arm64 libsasl2-dev -y
sudo apt install gcc-aarch64-linux-gnu
sudo apt-get install build-essential gcc make perl dkms
touch $HOME/.cargo/config && cd $HOME/.cargo
echo "[target.aarch64-unknown-linux-gnu]" >> ./config
echo "linker = \"/usr/bin/aarch64-linux-gnu-gcc\"" >> ./config

Looking for help and suggestions for this, thank you very much

Description

Paths with .. in Rust code are interpreted as a directory called .. and not as the parent directory.

Workflow code

https://github.com/ReagentX/glicko2/blob/07c00b9dafa8305b1ed1a8ff1ebfe252ec5c8505/.github/workflows/test.yml

Action output

error: couldn't read src/../README.md: No such file or directory (os error 2)
11 --> src/lib.rs:2:9
12   |
13 2 | #[doc = include_str!("../README.md")]
14   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15   |
16   = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info)
17
18 error: could not compile `glicko2` due to previous error

Expected behavior

#[doc = include_str!("../README.md")] evaluates to the parent directory instead of a directory literally called .. (in the above error, src/../README.md)

Additional context

This works locally, just not in the action.

For example, see Ralith/hecs#4; as of this writing various attempts at this have spun for upwards of twenty minutes before being cancelled, while a local run completes in seconds. Not sure how to get any feedback from the action while it's running, so it's unclear what might be happening here.

Do the checklist before filing an issue:

• [ x ] Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• [ x ] You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• [ Not Sure ] Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

In my project, I'm seeing deprecation warnings about Node12. They look like:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: jetli/[email protected], actions-rs/cargo@v1

Could you update the action.yml file to use node16 as described in https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-javascript-actions

Thanks!

Workflow code

See above

Action output

See above

Expected behavior

No node12 warnings

Additional context

Add any other context about the problem here.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

I am running the action-rs fmt action with a specified manifest in a subdir --manifest-path ./2021/Cargo.toml and the action fail at finding the rustfmt.toml file that is in the parent folder, leading to the formating check to fail

Workflow code

fmt:
    name: Rustfmt
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/toolchain@v1
        with:
          profile: minimal
          toolchain: stable
          override: true
      - run: rustup component add rustfmt
      - uses: actions-rs/cargo@v1
        with:
          command: fmt
          args: --manifest-path ./2021/Cargo.toml --all -- --check 

Action output

Run actions-rs/cargo@v1
  with:
    command: fmt
    args: --manifest-path ./2021/Cargo.toml --all -- --check
    use-cross: false
/home/runner/.cargo/bin/cargo fmt --manifest-path ./2021/Cargo.toml --all -- --check
Diff in /home/runner/work/advent-of-code/advent-of-code/2021/src/common.rs at line 7:
 /// ```
 pub fn cartesian<I, E>(a: I, b: I) -> impl Iterator<Item = (E, E)>
 where

Expected behavior

The rustfmt command should be able to pull the config from the parent folder.

I have a question about running Cargo builds on macOS, and I was wondering if someone might know the answer.

We've been experience flaky builds (unicode-org/icu4x#201) caused by ephemeral build errors that appear to have started showing up all of a sudden on a few PRs.

The error message in the log mentions error[E0463]: can't find crate for serde_derive which serde depends on, and when I looked through serde-rs/serde#856 and similar issues (and verified the transitive dependencies' versions of serde used, using cargo-tree), I don't see the same serde version conflict problems that were described. And either way, I don't think that would explain the ephemeral nature.

One possible theory is that it might relate to this issue from 3 years ago of cargo build failing on macOS due to linking issues when dependencies are added (rust-lang/cargo#4775). I don't know if that is still relevant to cargo builds. The GH builds that use the GH caching action (thereby retrieving cargo crate cache) are the ones that seem to fail ephemerally (ex1, ex2). The tests run after I turned off the GH caching action seem to pass (ex1, ex2). And FWIW, in my personal fork, even when I leave the GH cache action on, the builds pass (ex1, ex2).

Any pointers or suggestions would be appreciated, thanks.

Motivation

Building a Rust project takes a lot of time if many dependencies are involved. In my case I have >2 minutes build time, of which only a few seconds are from my own crates. This could be greatly reduced by caching the target directory with the dependency cache.

Workflow example

steps:
  - name: Cargo check
    uses: actions-rs/cargo@v2
    with:
      command: check
      use-cache: true # cache the target directory between runs

Additional context

The action is actions/cache.

There is an example on how to use it for the .cargo directory. Employing that example prevents cargo from redownloading all the crates on every run, but it still recompiles them.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

Cross-compilation is super useful, but sadly cross is sometimes breaking things such as the compilation for powerpc64-unknown-linux-gnu and it doesn't really do semver when breaking stuff, but still has past versions we could use instead.

This project was already hit once: 4630dea

So I propose to be able to tag a cross version in the action.

Workflow example

  cross-test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        rust_target:
          - powerpc-unknown-linux-gnu
          - powerpc64-unknown-linux-gnu
          - powerpc64le-unknown-linux-gnu
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v2
      - name: Install Rust nightly
        uses: actions-rs/toolchain@v1
        with:
            toolchain: nightly
            profile: minimal
            target: ${{ matrix.rust_target }}
            default: true
      - name: Build
        uses: actions-rs/cargo@v1
        with:
          use-cross: v0.1.16
          command: build
          args: --target ${{ matrix.rust_target }}
      - name: Test
        uses: actions-rs/cargo@v1
        with:
          use-cross: true
          command: test
          args: --target ${{ matrix.rust_target }}

When nothing is specified in the "use-cross" field, it would just use the existing cross version or download the latest, but if something is specified, it should fetch that version of cross instead.

On all no_std supporting crates I typically need to test for no_std compatibility in CI. This blog has some useful advice on how this can be done. Is it possible this can be added here? Is this the right place? Thank you and much appreciated. I love actions-rs.

Here is a crate I am doing this as an example currently: https://github.com/rust-cv/eight-point

Hi @actions-rs!

Maintainer of https://github.com/krzema12/github-actions-kotlin-dsl here. Your actions have first-class support in the library.

Recently we've come up with a way to reduce operational load when keeping library's action wrappers in sync with action's inputs. The solution includes onboarding https://github.com/krzema12/github-actions-typing. It's as easy as adding an extra YAML file to your repository root, and adding a simple GitHub workflow that validates this new file. Thanks to this, the code generator in the Kotlin DSL can fetch typing info provided by you instead of us, which has a number of benefits. It has no negative effects on current action consumers, they continue to use the action via regular GitHub API, as if the file wasn't there. The typings themselves are unaware of the Kotlin DSL, and any other tool (let it be another code generator or documentation tool) can use the typings if you provide them.

In this feature request, I would like to ask you if you're open to introducing such typings in your actions. You wouldn't be first - there're already other actions using it: https://github.com/krzema12/github-actions-typing/network/dependents

If your answer is "yes", feel free to either add it yourself, or let me know - me or some of my fellow contributors would be happy to post PRs. We're also open to any kind of questions and feedback.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

Cache compilation of cross binary and docker images used by cross. This should speed up all actions using cross.

Workflow example

We may want to add an option to opt out of caching?

Additional context

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

On my GitHub Actions CI pipeline the actin-rs/cargo@v1 errors using the install command when, due to caching, the target crate is already installed.

Workflow code

My Workflow file:
https://github.com/mr-pascal/changelog-generator/actions/runs/3451578950/workflow
See the test_coverage job workflow.

# Install "grcov"
- uses: actions-rs/cargo@v1
  with:
    command: install
    args: grcov

Action output

Run actions-rs/cargo@v1
  with:
    command: install
    args: grcov
    use-cross: false
  env:
    RUSTFLAGS: -Cinstrument-coverage
    LLVM_PROFILE_FILE: coverage-%p-%m.profraw
/home/runner/.cargo/bin/cargo install grcov
    Updating crates.io index
error: binary `grcov` already exists in destination
Error: Add --force to overwrite
Error: The process '/home/runner/.cargo/bin/cargo' failed with exit code 101

Expected behavior

Instead of throwing an error and failing the job I would expect a plain "Ignored" notice, that the package already exists and the job just continues.

Additional context

I use caching in the workflow to speed it up significantly, as such also the previous installed grcov is kept in cache and available.

- uses: actions/cache@v3
  with:
    path: |
      ~/.cargo/bin/
      ~/.cargo/registry/index/
      ~/.cargo/registry/cache/
      ~/.cargo/git/db/
      target/
    key: ${{ runner.os }}-cargo-2-${{ hashFiles('**/Cargo.lock') }}

Using --force and just re-installing the crate is no option, since this would introduce also a re-compilation of the crate.

Hello! Thank you for this useful project

Description

A couple days ago my workflow stopped working without modification. Upon attempting to run cargo build with use-cross set to true I get this error:

Status: Downloaded newer image for clux/muslrust:latest
error: could not create home directory: '/.rustup'
Error: error: caused by: Permission denied (os error 13)
Error: The process 'cross' failed with exit code 1

Workflow code

Here is my workflow: https://github.com/gleam-lang/gleam/blob/e25991fe92901577b47b0c6d3d71894a7abbc5e0/.github/workflows/ci.yaml#L46-L51

I believe this to be a reproduction:

name: ci
on:
  pull_request:
  push:
    branches:
      - main
jobs:
  test:
    env:
      RUSTFLAGS: "-D warnings"
    name: test
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Install Rust toolchain
      uses: actions-rs/toolchain@v1
      with:
        toolchain: stable
        target: x86_64-unknown-linux-musl
        profile: minimal
        override: true

    - name: Build binary
      uses: actions-rs/cargo@v1
      with:
        use-cross: true
        command: build
        args: --release --target x86_64-unknown-linux-musl

Action output

Here is the full log https://github.com/gleam-lang/gleam/runs/2828986249?check_suite_focus=true

Expected behavior

cargo build runs

Thanks,
Louis

Do the checklist before filing an issue:

• [-] Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• [-] You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests

Motivation

one shot compile or build multiple project in one go.
alternative to one repo one project and reduce the amount of clicks needed for the ui.

Workflow example

If applicable, create an example on how this feature will look in the workflow yaml file.(pseudocode?)
 - uses action-rs/cargo
 - run:bashlooprecursive-dir(cargo build {matrix})

Additional context

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

My understanding is this github action only supports running cargo commands from the root of the repo. Is it possible to run cargo commands from a subdirectory? The motivation is that I have a monorepo that has projects that use different languages. I'd like to run cargo commands only for the rust projects.

Additional context

I've tried to set "working-directory" at the top level but that didn't seem to work.

This is my workflow file:

- name: Install stable with clippy and rustfmt
  uses: actions-rs/toolchain@v1
  with:
      profile: minimal
  toolchain: 1.65
  components: rustfmt, clippy

This is the logging:

Run actions-rs/toolchain@v1
with:
profile: minimal
toolchain: 1.65
components: rustfmt, clippy
default: false
override: false
env:
CARGO_TERM_COLOR: always
CARGO_NET_GIT_FETCH_WITH_CLI: true
SSH_AUTH_SOCK: /tmp/ssh-IvKvFOZfPPq0/agent.1518
SSH_AGENT_PID: 1519
/home/runner/.cargo/bin/rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/runner/.rustup

stable-x86_64-unknown-linux-gnu (default)
rustc 1.64.0 (a55dd71d5 2022-09-19)
/home/runner/.cargo/bin/rustup -V
rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.64.0 (a55dd71d5 2022-09-19)`
Installed rustup 1.25.1 support profiles
/home/runner/.cargo/bin/rustup -V
rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.64.0 (a55dd71d5 2022-09-19)`
Installed rustup 1.25.1 support components
/home/runner/.cargo/bin/rustup set profile minimal
info: profile set to 'minimal'
/home/runner/.cargo/bin/rustup toolchain install 1.65 --component rustfmt --component clippy
info: syncing channel updates for '1.65-x86_64-unknown-linux-gnu'
info: latest update on 2022-11-03, rust version 1.65.0 (897e37553 2022-11-02)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustfmt'

1.65-x86_64-unknown-linux-gnu installed - rustc 1.65.0 (897e37553 2022-11-02)

info: checking for self-updates
warning: tool `rustfmt` is already installed, remove it from `/home/runner/.cargo/bin`, then run `rustup update` to have rustup manage this tool.
warning: tool `cargo-fmt` is already installed, remove it from `/home/runner/.cargo/bin`, then run `rustup update` to have rustup manage this tool.
Gathering installed versions
/home/runner/.cargo/bin/rustc -V
rustc 1.64.0 (a55dd71d5 2022-09-19)
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
/home/runner/.cargo/bin/cargo -V
cargo 1.64.0 (387270bc7 2022-09-16)
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
/home/runner/.cargo/bin/rustup -V
rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.64.0 (a55dd71d5 2022-09-19)`
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Why isn't Rust 1.65 installed? Now I get this errors on my CI but it works locally:

``let...else statements are unstable

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

Describe your idea, motivation, and how Rust community could benefit from this feature.
To implement compiler environment variables without the using a config.toml file

Workflow example

If applicable, create an example on how this feature will look in the workflow yaml file

• name: Build for Armv7
  uses: actions-rs/[email protected]
  with:
  command: build
  args: --target armv7-unknown-linux-gnueabihf
  env: |
  OPENSSL: ${{ github.workspace }}/openssl_android #arm
  OPENSSL_DIR: ${{ github.workspace }}/openssl_android

Additional context

Add any additional information about this feature; that includes links to the related tools, alternative implementations, blog posts and so on

Description

When running, we get a warning for rustfmt and cargo-fmt.

Workflow code

- name: Build amd64
  uses: actions-rs/cargo@v1
  with:
    command: build
    use-cross: true
    args: --release --target x86_64-unknown-linux-musl

Reference yaml:
https://github.com/giggio/speedtest/blob/4ab093da7cebc6c0e7430bb4aba761e92c81df3b/.github/workflows/image.yml#L40-L45

Action output

warning: tool `rustfmt` is already installed, remove it from `/home/runner/.cargo/bin`, then run `rustup update` to have rustup manage this tool.
Warning: warning: tool `cargo-fmt` is already installed, remove it from `/home/runner/.cargo/bin`, then run `rustup update` to have rustup manage this tool.

See the warning on the action:
https://github.com/giggio/speedtest/runs/6816591384?check_suite_focus=true#step:8:13

Expected behavior

No warnings.

Additional context

Happens for ARM and amd64, they are both on the build output and yaml.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Paste that part of your workflow yaml file that causes the bug in here.

Alternatively you can remove that code block and insert direct link to your workflow file.
Ensure that link points to the specific commit, and not just to the master branch.

Action output

Copy and paste Action output logs in here.

How else can you help on that step:
1. Enable debug logs first: https://github.com/actions/toolkit/blob/master/docs/action-debugging.md
2. Re-run the job
2. Download logs archive for job run and attach it to this issue

Expected behavior

A clear and concise description of what you expected to happen.

Additional context

Add any other context about the problem here.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

Cargo now offers the rust-toolchain.toml file which allows a project to specify what toolchain details it needs. Currently, actions-rs requires you to set up two actions:

• actions-rs/toolchain@v1 - install the toolchain things you need
• actions-rs/cargo@v1 - run cargo (i.e. build)

Instead, the actions-rs/cargo@v1 action could detect if no toolchain was manually specified in the actions yml. If not, it should read rust-toolchain.toml and install all the required stuff automatically.

Workflow example

rust-toolchain.toml:

[toolchain]
channel = "nightly-2021-09-30"
targets = ["x86_64-unknown-linux-gnu", "x86_64-unknown-linux-musl"]
profile = "minimal"

.github/workflows/test.yml:

on: [push]

name: CI

jobs:
  build_and_test:
    name: Rust project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/cargo@v1
        with:
          command: build
          args: --release --all-features

Notice the lack of any reference to actions-rs/toolchain@v1. Instead, actions-rs/cargo@v1 will install everything required as specified in the rust-toolchain.toml file.

Additional context

https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file

Description

I am trying to build my project for arm-unknown-linux-gnueabihf using a slight modified version of the cross example that's provided in the README.md. The Build fails when trying to parse a manifest in the Cargo.toml.

Workflow code

This is the workflow file.

Action output

Log from my run:

Downloaded hyper v0.10.16
error: failed to parse manifest at `/cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.10.16/Cargo.toml`
##[error]failed to parse manifest at `/cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.10.16/Cargo.toml`
Caused by:
readme file with name 'README.md' was not found
##[error]The process 'cross' failed with exit code 101

In another run the same error occurs with a different crate: ##[error]failed to parse manifest at /cargo/registry/src/github.com-1ecc6299db9ec823/time-macros-impl-0.1.1/Cargo.toml

Expected behavior

I tried building my project locally with cross for the same target without this happening.

It is usually PITA to determine the path where build artifacts were placed, because resulting path might vary based on the debug/release profile and compilation target name, ex:

• target/debug/
• target/release/
• target/x86_64-pc-windows-gnu/release/

and so on.
Since it is often used to continue CI process, it would be great to add this path into the Action outputs.
Note: it is not the same as OUT_DIR env var provided for build.rs scripts, but it might be worth to export it too.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests

Motivation

Some have strict limits on rust binary size, such as AWS Lambdas.

https://crates.io/crates/xargo