1
0
mirror of https://github.com/containers/youki synced 2024-11-23 01:11:58 +01:00
youki/scripts
Jorge Prendes ff79c54968
(feat) add support for musl using cross-rs (#2536)
* add cross configuration for musl

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>

* use cargo.sh wapper in build.sh

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>

* make tests build with musl

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>

* add targets to run musl tests

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>

* Use cargo.sh wrapper and cross in CI

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>

* Update scripts/cargo.sh

Co-Authored-By: adrianalin <pop.adrian61@gmail.com>
Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>

* Use glibc as cross default target

---------

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>
Co-authored-by: adrianalin <pop.adrian61@gmail.com>
2023-12-21 11:50:03 +00:00
..
.gitignore Add scripts to build binaries, run rust integration tests and clean up 2022-02-06 16:01:13 +05:30
build.sh (feat) add support for musl using cross-rs (#2536) 2023-12-21 11:50:03 +00:00
cargo.sh (feat) add support for musl using cross-rs (#2536) 2023-12-21 11:50:03 +00:00
clean.sh (feat) add support for musl using cross-rs (#2536) 2023-12-21 11:50:03 +00:00
features_test.sh (feat) add support for musl using cross-rs (#2536) 2023-12-21 11:50:03 +00:00
oci_integration_tests.sh Using typos-cli to catch typos + fixes for existing typos (#2018) 2023-06-08 10:19:17 +05:30
README.md Update the docs for the directory structure changes (#813) 2022-04-13 20:59:52 +02:00
release_tag.sh Simplify release workflow (#2541) 2023-12-16 11:01:06 +09:00
rust_integration_tests.sh Refactor test dir structure (#2421) 2023-10-10 21:00:02 +09:00

Scripts

This stores various scripts that do various things. These can be intended to be used directly, or can be for using from some other scripts or Makefiles.

Note

Please use set -e at the start of every script. This will ensure that the operation fails if any single command fails in that script. Without it, the script will continue after the failing command and might create a knock-on effect of incorrect results. In case you expect some step to fail, handle the failure directly rather than checking some condition to see if the command is successful in the rest of the script.