[cargo]: cargo/build pipeline improvements

[kranurag7]

This issue tracks improving our cargo/build pipeline to be more flexible and allow more wide usage of this pipeline across our package repositories.

We've certain limitations when we use cargo/build pipeline and below are the notes about the same.

1. As of now, the pipeline fails if we define a different modroot other than .

  - name: build linkerd-network-validator
    uses: cargo/build
    with:
      modroot: ./validator
      output: linkerd-network-validator
      install-dir: lib/linkerd

The reason for failure here is that cargo stores the binary root of the tree under target directory.

      cd "${{inputs.modroot}}"

In here, we change the directory to a different one and binary is stored at root.

After build, When we are invoking the install command in the pipeline it's not able to find the directory.

        install -Dm755 "${OUTPUT_PATH}/${{inputs.output}}" "${INSTALL_PATH}/${{inputs.output}}"

The solution here is to use CARGO_TARGET_DIR environment variable but maybe there's also a simpler way to do this.

2. custom binary name
   unlike go -o flag, cargo doesn't have a similar flag but there's an experimental feature in cargo to specify custom binary name in there.
   https://doc.rust-lang.org/cargo/reference/unstable.html#different-binary-name

cargo new foo
cd foo
cargo run
cargo build

In above case, the binary name is always foo

If we want to change the binary name then we'll have to specify it something like this.

[[bin]]
name = "sammy"
path = "src/main.rs"

and then when we invoke cargo build or cargo run the binary name is sammy

[ckoehler]

Are these fixes related to #1582 ?

[kranurag7]

@ckoehler I didn't had a chance to look at the issue in detail, I quickly skimmed over it.

but this fixes are in general for every package that relies on cargo/build.

In wolfi-dev/os repository, you can do the following to test it out.

make dev-container
make package/geckodriver

If you add your config in there and build it then you should be able to proceed ahead. In general, I always use the dev-container environment for building purpose.
If you still want to build without docker then maybe this command is more accurate than a simple melange build

./melange build foo.yaml --arch=x86_64 --repository-append /home/user/second-os/packages --keyring-append /home/user/second-os/local-melange.rsa.pub -k https://packages.wolfi.dev/os/wolfi-signing.rsa.pub -r https://packages.wolfi.dev/os

it requires more args than you're using in your command.

[ckoehler]

Thanks for that. I updated the issue with the same run using the (latest) Docker image, the same error happens.