pass --target-dir with cargo/build pipeline #1592
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this patch passes
--target-dir
flag with cargo at build time.This is required because
cargo/build
pipeline uses modroot and when wecd
into a specific directory and invoke cargo build, the resulting binary still ends up in root of the repository atGIT_ROOT_DIR/target/release/foo
After which when we use the following install command it fails to find the binary.
by passing
--target-dir
flag to target, we are creating thetarget/release/foo
binary in the current working directory hence the install command will succeed.This change is looking good considering backwards compatibility with the use of this pipeline in existing package.
We change the existing
modroot
name tomanifest-path
and invoke all the commands from the root of the repository.we can keep using the word
modroot
as well but IMHOmanifest-path
closely aligns with cargo terminology.We then need to point this to
Cargo.toml
in different directory and the result will always be stored at root of the repository insidetarget/release
ortarget/debug
directory depending on the profile we are building for.To me, this looks like a more better solution than the proposed one but this will break one existing package because of name change https://github.com/wolfi-dev/os/blob/main/geckodriver.yaml
I proceeded with first option because the alternative consideration was breaking one package.
related: #1590