shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2024-12-23 21:35:26 +03:00
Code Issues Projects Releases Wiki Activity
63bf5e606b
ostree/tests/test-admin-deploy-etcmerge-cornercases.sh

152 lines
5.8 KiB
Bash
Raw Normal View History

Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
#!/bin/bash
#
# Copyright (C) 2013 Colin Walters <walters@verbum.org>
#
Add SPDX-License-Identifier to source files SPDX License List is a list of (common) open source licenses that can be referred to by a “short identifier”. It has several advantages compared to the common "license header texts" usually found in source files. Some of the advantages: * It is precise; there is no ambiguity due to variations in license header text * It is language neutral * It is easy to machine process * It is concise * It is simple and can be used without much cost in interpreted environments like java Script, etc. * An SPDX license identifier is immutable. * It provides simple guidance for developers who want to make sure the license for their code is respected See http://spdx.org for further reading. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Closes: #1439 Approved by: cgwalters
2018-01-30 22:26:26 +03:00
# SPDX-License-Identifier: LGPL-2.0+
#
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
tests: Use "bash strict mode" I noticed in the static deltas tests, there were some tests that should have been under `-o pipefail` to ensure we properly propagate errors. There were a few places where we were referencing undefined variables. Overall, this is clearly a good idea IMO.
2016-01-27 19:44:10 +03:00
set -euo pipefail
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
. $(dirname $0)/libtest.sh
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
# Exports OSTREE_SYSROOT so --sysroot not needed.
tree-wide: Replace archive-z2 with archive In almost all places. There are just a few exceptions; one tricky bit for example is that the repo config must still have `mode=archive-z2`, since `archive` used to mean something else. (We could very likely just get rid of that check, but eh, later). I also added a test that one can still do `ostree repo init --mode=archive-z2`. Closes: #1125 Approved by: jlebon
2017-09-01 23:15:33 +03:00
setup_os_repository "archive" "syslinux"
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo pull-local --remote=testos testos-repo testos/buildmain/x86_64-runtime
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
export rev
echo "rev=${rev}"
# This initial deployment gets kicked off with some kernel arguments
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --karg=root=LABEL=MOO --karg=quiet --os=testos testos:testos/buildmain/x86_64-runtime
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
assert_has_dir sysroot/boot/ostree/testos-${bootcsum}
etc=sysroot/ostree/deploy/testos/deploy/${rev}.0/etc
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
# modified config file
echo "a modified config file" > ${etc}/NetworkManager/nm.conf
# Ok, let's create a long directory chain with custom permissions
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
mkdir -p ${etc}/a/long/dir/chain
mkdir -p ${etc}/a/long/dir/forking
chmod 700 ${etc}/a
chmod 770 ${etc}/a/long
chmod 777 ${etc}/a/long/dir
chmod 707 ${etc}/a/long/dir/chain
chmod 700 ${etc}/a/long/dir/forking
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
# Symlink to nonexistent path, to ensure we aren't walking symlinks
ln -s no-such-file ${etc}/a/link-to-no-such-file
deploy: Ignore sockets, fifos in /etc during merge https://bugzilla.redhat.com/show_bug.cgi?id=1945274 is an issue where a privileged kubernetes daemonset is writing a socket into `/etc`. This makes ostree upgrades barf. Now, they should clearly move it to `/run`. However, one option is for us to just ignore it instead of erroring out. Some brief investigation shows that e.g. `git add somesocket` is a silent no-op, which is an argument in favor of ignoring it. Closes: https://github.com/ostreedev/ostree/issues/2446
2021-09-30 22:53:18 +03:00
# fifo which should be ignored
mkfifo "${etc}/fifo-to-ignore"
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
# Remove a directory
rm ${etc}/testdirectory -rf
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
# Now deploy a new commit
os_repository_new_commit
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo remote add --set=gpg-verify=false testos file://$(pwd)/testos-repo testos/buildmain/x86_64-runtime
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
echo "newrev=${newrev}"
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
newroot=sysroot/ostree/deploy/testos/deploy/${newrev}.0
newetc=${newroot}/etc
assert_file_has_content ${newroot}/usr/etc/NetworkManager/nm.conf "a default daemon file"
assert_file_has_content ${newetc}/NetworkManager/nm.conf "a modified config file"
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
deploy: Ignore sockets, fifos in /etc during merge https://bugzilla.redhat.com/show_bug.cgi?id=1945274 is an issue where a privileged kubernetes daemonset is writing a socket into `/etc`. This makes ostree upgrades barf. Now, they should clearly move it to `/run`. However, one option is for us to just ignore it instead of erroring out. Some brief investigation shows that e.g. `git add somesocket` is a silent no-op, which is an argument in favor of ignoring it. Closes: https://github.com/ostreedev/ostree/issues/2446
2021-09-30 22:53:18 +03:00
if test -e "${newetc}"/fifo-to-ignore; then
fatal "Should not have copied fifo!"
fi
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
assert_file_has_mode() {
stat -c '%a' $1 > mode.txt
if ! grep -q -e "$2" mode.txt; then
echo 1>&2 "file $1 has mode $(cat mode.txt); expected $2";
exit 1
fi
rm -f mode.txt
}
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
Move xattr handling into libgsystem, fix sysroot to handle directory ownership/perms This large patch moves the core xattr logic down into libgsystem, which allows the gs_shutil_cp_a() API to copy them. In turn, this allows us to just use that API instead of rolling our own recursive copy here. As noted in the new comment though, one case that we are explicitly regressing is where the new /etc removes a parent directory that's needed by a modified file. This seems unlikely for most vendors now, but let's do that as a separate bug. https://bugzilla.gnome.org/show_bug.cgi?id=711058
2013-11-19 04:47:46 +04:00
assert_file_has_mode ${newetc}/a 700
assert_file_has_mode ${newetc}/a/long 770
assert_file_has_mode ${newetc}/a/long/dir 777
assert_file_has_mode ${newetc}/a/long/dir/chain 707
assert_file_has_mode ${newetc}/a/long/dir/forking 700
assert_file_has_mode ${newetc}/a/long/dir 777
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
test -L ${newetc}/a/link-to-no-such-file || assert_not_reached "should have symlink"
assert_has_dir ${newroot}/usr/etc/testdirectory
assert_not_has_dir ${newetc}/testdirectory
tests: Add new TAP APIs Having to touch a global test counter when adding tests is a recipe for conflicts between PRs. The TAP protocol allows *ending* with the expected number of tests, so the best way to do this is to have an explicit API like our `tap_ok` which bumps a counter, then end with `tap_end`. I ported one test as a demo.
2021-09-11 00:07:42 +03:00
tap_ok first
tests: Add a test for an empty /etc directory gaining content https://bugzilla.gnome.org/show_bug.cgi?id=731924
2014-06-19 23:53:20 +04:00
# Add /etc/initially-empty
cd "${test_tmpdir}/osdata"
mkdir -p usr/etc/initially-empty
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=${test_tmpdir}/testos-repo commit -b testos/buildmain/x86_64-runtime -s "Add empty directory"
tests: Add a test for an empty /etc directory gaining content https://bugzilla.gnome.org/show_bug.cgi?id=731924
2014-06-19 23:53:20 +04:00
cd ${test_tmpdir}
# Upgrade, check that we have it
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
tests: Add a test for an empty /etc directory gaining content https://bugzilla.gnome.org/show_bug.cgi?id=731924
2014-06-19 23:53:20 +04:00
assert_has_dir sysroot/ostree/deploy/testos/deploy/$rev.0/etc/initially-empty
# Now add a two files in initially-empty
cd "${test_tmpdir}/osdata"
touch usr/etc/initially-empty/{afile,bfile}
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=${test_tmpdir}/testos-repo commit -b testos/buildmain/x86_64-runtime -s "Add empty directory"
tests: Add a test for an empty /etc directory gaining content https://bugzilla.gnome.org/show_bug.cgi?id=731924
2014-06-19 23:53:20 +04:00
# Upgrade, check that we have the two new files
cd ${test_tmpdir}
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
tests: Add a test for an empty /etc directory gaining content https://bugzilla.gnome.org/show_bug.cgi?id=731924
2014-06-19 23:53:20 +04:00
assert_has_file sysroot/ostree/deploy/testos/deploy/$rev.0/etc/initially-empty/afile
assert_has_file sysroot/ostree/deploy/testos/deploy/$rev.0/etc/initially-empty/bfile
deploy: Consistently use fd-relative API While looking to fix a different bug here, I found the current state of things where we had a mix of fd-relative API versus not frustrating. Change the code around to consistently use *at, and also add some more tests.
2014-09-13 18:36:59 +04:00
# Replace config file with default directory
cd "${test_tmpdir}/osdata"
mkdir usr/etc/somenewdir
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=${test_tmpdir}/testos-repo commit -b testos/buildmain/x86_64-runtime -s "Add default dir"
deploy: Consistently use fd-relative API While looking to fix a different bug here, I found the current state of things where we had a mix of fd-relative API versus not frustrating. Change the code around to consistently use *at, and also add some more tests.
2014-09-13 18:36:59 +04:00
cd ${test_tmpdir}
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
deploy: Consistently use fd-relative API While looking to fix a different bug here, I found the current state of things where we had a mix of fd-relative API versus not frustrating. Change the code around to consistently use *at, and also add some more tests.
2014-09-13 18:36:59 +04:00
newconfpath=sysroot/ostree/deploy/testos/deploy/${rev}.0/etc/somenewdir
echo "some content blah" > ${newconfpath}
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
if ${CMD_PREFIX} ostree admin upgrade --os=testos 2>err.txt; then
deploy: Consistently use fd-relative API While looking to fix a different bug here, I found the current state of things where we had a mix of fd-relative API versus not frustrating. Change the code around to consistently use *at, and also add some more tests.
2014-09-13 18:36:59 +04:00
assert_not_reached "upgrade should have failed"
fi
assert_file_has_content err.txt "Modified config file newly defaults to directory"
rm ${newconfpath}
# Remove parent directory of modified config file
cd "${test_tmpdir}/osdata"
rm -rf usr/etc/initially-empty
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=${test_tmpdir}/testos-repo commit -b testos/buildmain/x86_64-runtime -s "Remove default dir"
deploy: Consistently use fd-relative API While looking to fix a different bug here, I found the current state of things where we had a mix of fd-relative API versus not frustrating. Change the code around to consistently use *at, and also add some more tests.
2014-09-13 18:36:59 +04:00
cd ${test_tmpdir}
newconfpath=sysroot/ostree/deploy/testos/deploy/${rev}.0/etc/initially-empty/mynewfile
touch ${newconfpath}
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
deploy: Copy parent directories for modified config files Previously, in the case where a parent directory of a modified config file was removed, we would throw an exception. This happens when switching from a tree that has some software (e.g. firewalld), to one that does not. While it's nice to have this warning that your config file probably no longer applies, there's no need to make it so...fatal. It's particularly problematic that the only easy workaround is to remove the config files from your current tree - which breaks rollback. The solution then is for for us to take ownership of the parent directories too into the new /etc. Admins can clean up these files afterwards at any time. https://bugzilla.gnome.org/show_bug.cgi?id=734293
2014-09-15 17:29:26 +04:00
assert_not_has_file sysroot/ostree/deploy/testos/deploy/${rev}.0/usr/etc/initially-empty
assert_has_file sysroot/ostree/deploy/testos/deploy/${rev}.0/etc/initially-empty/mynewfile
deploy: Consistently use fd-relative API While looking to fix a different bug here, I found the current state of things where we had a mix of fd-relative API versus not frustrating. Change the code around to consistently use *at, and also add some more tests.
2014-09-13 18:36:59 +04:00
rm ${newconfpath}
tests: Add new TAP APIs Having to touch a global test counter when adding tests is a recipe for conflicts between PRs. The TAP protocol allows *ending* with the expected number of tests, so the best way to do this is to have an explicit API like our `tap_ok` which bumps a counter, then end with `tap_end`. I ported one test as a demo.
2021-09-11 00:07:42 +03:00
tap_ok second
tap_end
Reference in New Issue Copy Permalink