rpm-ostree/tests/compose-tests/libcomposetest.sh

46 lines
1.2 KiB
Bash
Raw Normal View History

dn=$(cd $(dirname $0) && pwd)
. ${dn}/../common/libtest.sh
test_tmpdir=$(mktemp -d /var/tmp/rpm-ostree-compose-test.XXXXXX)
touch ${test_tmpdir}/.test
trap _cleanup_tmpdir EXIT
cd ${test_tmpdir}
pyeditjson() {
cat >editjson.py <<EOF
import sys,json
jd=json.load(sys.stdin)
${1}
json.dump(jd,sys.stdout)
EOF
python ./editjson.py && rm -f ./editjson.py
}
pysetjsonmember() {
pyeditjson "jd['"$1"'] = $2" < ${treefile} > ${treefile}.new && mv ${treefile}{.new,}
}
pyappendjsonmember() {
pyeditjson "jd['"$1"'] += $2" < ${treefile} > ${treefile}.new && mv ${treefile}{.new,}
}
prepare_compose_test() {
name=$1
shift
cp -r ${dn}/../composedata .
export treefile=composedata/fedora-${name}.json
pyeditjson "jd['ref'] += \"/${name}\"" < composedata/fedora-base.json > ${treefile}
# FIXME extract from json
export treeref=fedora/stable/x86_64/${name}
}
bin/compose: Expose phases as [install, postprocess, commit] cmds Right now `rpm-ostree compose tree` is very prescriptive about how things work. Trying to add anything that isn't an RPM is absolutely fighting the system. Our postprocessing system *enforces* no network access (good for reproducibilty, but still prescriptive). There's really a logical split between three phases: - install: "build a rootfs that installs packages" - postprocess: "run magical ostree postprocessing like kernel" - commit: "commit result to ostree" So there are two high level flows I'd like to enable here. First is to allow people to do *arbitrary* postprocessing between `install` and `commit`. For example, run Ansible and change `/etc`. This path basically is like what we have today with `postprocess-script.sh`, except the builder can do anything they want with network access enabled. Going much farther, this helps us support a "build with Dockerfile" style flow. We can then provide tooling to extract the container image, and combine `postprocess` and `commit`. Or completely the other way - if for example someone wants to use `rpm-ostree compose install`, they could tar up the result as a Docker/OCI image. That's now easier; an advantage of this flow over e.g. `yum --installroot` is the "change detection" code we have. Related issues/PRs: - https://github.com/projectatomic/rpm-ostree/pull/96 - https://github.com/projectatomic/rpm-ostree/issues/471 One disadvantage of this approach right now is that if one *does* go for the split approach, we lose the "input hash" metadata for example. And down the line, I'd like to add even more metadata, like the input rpm repos, which could also be rendered on the client side. But, I think we can address that later by e.g. caching the metadata in a file in the install root and picking it back up or something. Closes: #1039 Approved by: jlebon
2017-10-12 21:56:08 +03:00
compose_base_argv="--repo=${repobuild} --cache-only --cachedir=${test_compose_datadir}/cache"
runcompose() {
bin/compose: Expose phases as [install, postprocess, commit] cmds Right now `rpm-ostree compose tree` is very prescriptive about how things work. Trying to add anything that isn't an RPM is absolutely fighting the system. Our postprocessing system *enforces* no network access (good for reproducibilty, but still prescriptive). There's really a logical split between three phases: - install: "build a rootfs that installs packages" - postprocess: "run magical ostree postprocessing like kernel" - commit: "commit result to ostree" So there are two high level flows I'd like to enable here. First is to allow people to do *arbitrary* postprocessing between `install` and `commit`. For example, run Ansible and change `/etc`. This path basically is like what we have today with `postprocess-script.sh`, except the builder can do anything they want with network access enabled. Going much farther, this helps us support a "build with Dockerfile" style flow. We can then provide tooling to extract the container image, and combine `postprocess` and `commit`. Or completely the other way - if for example someone wants to use `rpm-ostree compose install`, they could tar up the result as a Docker/OCI image. That's now easier; an advantage of this flow over e.g. `yum --installroot` is the "change detection" code we have. Related issues/PRs: - https://github.com/projectatomic/rpm-ostree/pull/96 - https://github.com/projectatomic/rpm-ostree/issues/471 One disadvantage of this approach right now is that if one *does* go for the split approach, we lose the "input hash" metadata for example. And down the line, I'd like to add even more metadata, like the input rpm repos, which could also be rendered on the client side. But, I think we can address that later by e.g. caching the metadata in a file in the install root and picking it back up or something. Closes: #1039 Approved by: jlebon
2017-10-12 21:56:08 +03:00
rpm-ostree compose tree ${compose_base_argv} ${treefile} "$@"
ostree --repo=${repo} pull-local ${repobuild}
}
prepare_run_compose() {
prepare_compose_test $1
runcompose
}