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

environment variables are not passed #912

Closed
3 of 11 tasks
hazkell opened this issue Jul 5, 2022 · 7 comments
Closed
3 of 11 tasks

environment variables are not passed #912

hazkell opened this issue Jul 5, 2022 · 7 comments
Labels
bug duplicate needs-information needs more information to replicate

Comments

@hazkell
Copy link

hazkell commented Jul 5, 2022

Checklist

Describe your issue

cross stopped compiling after last update.
I am using environment variables and now they are not passed for the following targets:

  • x86_64-unknown-linux-musl
  • i686-unknown-linux-musl
  • arm-unknown-linux-musleabi
  • aarch64-unknown-linux-musl

I do have the Cross.toml file and I am able to see environment variables in the debug output of the action.

What target(s) are you cross-compiling for?

aarch64-unknown-linux-musl, arm-unknown-linux-musleabi, i686-unknown-linux-musl, x86_64-unknown-linux-musl

Which operating system is the host (e.g computer cross is on) running?

  • macOS
  • Windows
  • Linux / BSD
  • other OS (specify in description)

What architecture is the host?

  • x86_64 / AMD64
  • arm32
  • arm64 (including Mac M1)

What container engine is cross using?

  • docker
  • podman
  • other container engine (specify in description)

cross version

cross 0.2.2

Example

- name: Build release
  uses: actions-rs/cargo@v1
  env:
    SOM_KEY: ${{ secrets.SOME_KEY }}
    TARGET: ${{ matrix.binary_target }}${{ matrix.ext }}
  with:
    use-cross: true
    command: build
    args: --release --target ${{ matrix.binary_target }}

Additional information / notes

No response

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Jul 5, 2022

This is a bug I believe that was documented in #863 and patched in #867. Try setting them in build.env as a temporary workaround or install from git (cargo install cross --git https://github.com/cross-rs/cross). We should be releasing 0.2.3 with this patch very soon. Check to see if that fixes the issue.

It would help if you pass the --verbose flag to the build output and your passthrough variables (only a portion of your Cross.toml is fine) since we can't really help without it. A minimum reproducible example is useful if you can't share your config for any reason.

@Alexhuszagh Alexhuszagh added bug needs-information needs more information to replicate labels Jul 5, 2022
@hazkell
Copy link
Author

hazkell commented Jul 6, 2022

Cross.toml

[build.env]
passthrough = [
    "SOME_KEY"
]

Temporarily switched to 0.2.1 and it still gives the same error, therefore must be unrelated to 0.2.2.
here is the github actions log (if it is not enough, tell which parts should I include):

Run actions-rs/cargo@v1
  with:
    use-cross: true
    command: build
    args: --verbose  --release --target x86_64-unknown-linux-musl
  env:
    SOME_KEY: ***

Installing "cross = latest"

cross build --verbose --release --target x86_64-unknown-linux-musl
+ cargo metadata --format-version 1 --filter-platform x86_64-unknown-linux-musl
+ rustc --print sysroot
+ rustup toolchain list
+ rustup target list --toolchain stable-x86_64-unknown-linux-gnu
+ rustup component list --toolchain stable-x86_64-unknown-linux-gnu
+ rustup component add rust-src --toolchain stable-x86_64-unknown-linux-gnu
info: downloading component 'rust-src'
info: installing component 'rust-src'
+ /usr/bin/docker
+ /usr/bin/docker run --userns host -e 'PKG_CONFIG_ALLOW_CROSS=1' -e 'XARGO_HOME=/xargo' -e 'CARGO_HOME=/cargo' -e 'CARGO_TARGET_DIR=/target' -e 'CROSS_RUNNER=' -e 'USER=runner' --rm --user 1001:121 -v /home/runner/.xargo:/xargo:Z -v /home/runner/.cargo:/cargo:Z -v /cargo/bin -v /home/runner/work/xxx/xxx:/project:Z -v /home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu:/rust:Z,ro -v /home/runner/work/xxx/xxx/target:/target:Z -w /project rustembedded/cross:x86_64-unknown-linux-musl-0.2.1 sh -c 'PATH=$PATH:/rust/bin cargo build --verbose --release --target x86_64-unknown-linux-musl'
Unable to find image 'rustembedded/cross:x86_64-unknown-linux-musl-0.2.1' locally
x86_64-unknown-linux-musl-0.2.1: Pulling from rustembedded/cross

Code producing the issue:

-- consts.rs
const SOME_KEY: &str = env!("SOME_KEY");

@Emilgardis
Copy link
Member

Why are you using an old image with 0.2.2?

Can you post the full Cross.toml?

@hazkell
Copy link
Author

hazkell commented Jul 6, 2022

[build.env]
passthrough = [
    "SOME_KEY"
]

[target.aarch64-unknown-linux-musl]
image = "rustembedded/cross:aarch64-unknown-linux-musl-0.2.1"

[target.arm-unknown-linux-musleabi]
image = "rustembedded/cross:arm-unknown-linux-musleabi-0.2.1"

[target.i686-unknown-linux-musl]
image = "rustembedded/cross:i686-unknown-linux-musl-0.2.1"

[target.x86_64-unknown-linux-musl]
image = "rustembedded/cross:x86_64-unknown-linux-musl-0.2.1"

@hazkell
Copy link
Author

hazkell commented Jul 6, 2022

Why are you using an old image with 0.2.2?

Can you post the full Cross.toml?

I thought the issue was with 0.2.2 as 0.2.1 was passing, but it seems that something was changed in code.

@Emilgardis
Copy link
Member

Emilgardis commented Jul 6, 2022

Aha, I see, you've not actually tested 0.2.1 then, the images don't contain any code for how the environment variables are passed to docker. To test 0.2.1 you need to have 0.2.1 installed

Instead, try installing cross from current main, you can do this in ci before your use-cross: true action

- name: Install cross from main
  run: cargo install cross --git https://github.com/cross-rs/cross

- name: Build release
  uses: actions-rs/cargo@v1
  env:
    SOM_KEY: ${{ secrets.SOME_KEY }}
    TARGET: ${{ matrix.binary_target }}${{ matrix.ext }}
  with:
    use-cross: true
    command: build
    args: --release --target ${{ matrix.binary_target }}

this issue is very much what was described in #863

We will have a 0.2.3 version out soon, but above will work well

@Alexhuszagh
Copy link
Contributor

I believe this is fixed? If the issue still persists, or is not related to #863, not I will re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug duplicate needs-information needs more information to replicate
Projects
None yet
Development

No branches or pull requests

3 participants