keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
1e50821bcb
rpm-ostree/tests/compose/test-rojig-pure.sh

38 lines
998 B
Bash
Raw Normal View History

Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
#!/bin/bash
set -xeuo pipefail
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
dn=$(cd "$(dirname "$0")" && pwd)
# shellcheck source=libcomposetest.sh
. "${dn}/libcomposetest.sh"
Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
rpm-ostree --version > version.txt
if ! grep -q rojig version.txt; then
echo "ok skip no rojig support"
exit 0
fi
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
treefile_set "automatic-version-prefix" '"42"'
treefile_set "documentation" 'True'
Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
mkdir rojig-repo
runcompose() {
(cd rojig-repo && createrepo_c .) && \
rm -f treecompose.json && \
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
runasroot rpm-ostree compose rojig --write-composejson-to $(pwd)/treecompose.json --cachedir=$(pwd)/cache ${treefile} $(pwd)/rojig-repo "$@" && \
Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
(cd rojig-repo && createrepo_c .)
}
runcompose
test -f treecompose.json
tests: Make more resistant to releasever changes Now that cosa and FCOS have moved to f32, a bunch of tests are breaking. Let's make them more resistant to releasever changes. While we're here though, bump the container image we use on the target host to f32, and update the systemd example output.
2020-06-02 16:57:05 +03:00
test -f rojig-repo/x86_64/fedora-coreos-42-1.fc*.x86_64.rpm
Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
echo "ok rojig ♲📦 initial"
runcompose
test '!' -f treecompose.json
echo "ok rojig no changes"
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
treefile_set "documentation" 'False'
Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
runcompose
test -f treecompose.json
tests: Make more resistant to releasever changes Now that cosa and FCOS have moved to f32, a bunch of tests are breaking. Let's make them more resistant to releasever changes. While we're here though, bump the container image we use on the target host to f32, and update the systemd example output.
2020-06-02 16:57:05 +03:00
test -f rojig-repo/x86_64/fedora-coreos-42.1-1.fc*.x86_64.rpm
Add `compose rojig` command This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon
2018-09-18 15:48:38 +03:00
echo "ok rojig dropped docs"
Reference in New Issue Copy Permalink