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

32 lines
877 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
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/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
test -f rojig-repo/x86_64/fedora-coreos-42-1.fc31.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/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
test -f rojig-repo/x86_64/fedora-coreos-42.1-1.fc31.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