We move some of the OpenPGP support into this file, which we will extend
once we switch to use the OpenPGP Stateless OpenPGP support.
Change-Id: I56acd993cb394dd8bc12a8da3cf4c78088adb61b
Rename gpg to pgp or OpenPGP and remove crypted from filenames.
The standard is called OpenPGP, GnuPG (or GPG, gpg) is one of many
implementations (although depending on the context the prevalent one)
so we use that when referring to the specification.
For the encrypted tarball we remove the «-crypted» term which is an
odd wording use for encryted content and it is unnecessary and confusing
when using layered containers (as when the tarball is decrypted the
name becomes invalid); and make it use «.pgp» instead of «.gpg» as
extension, while trying the old filename on decryption for backwards
compatibility.
Change-Id: If5e0349ff0c3d8e3b47ced361e9e77d7d4d2defc
We check whether we have both a sites.yml and a sites/ directory.
If so, and multi-sites support is enabled, then we proceed to load
all the multi-sites configurations, by placing each of them under
«sites.<site-name>.<config>». Adding a «sites.current» link to the
current site, and filling the root tree config with the current site
as well for backwards compatibility.
Change-Id: Ia810f57e8e976eef6a7582bddda46c1701456ed6
We currently only fix up owner and permissions for known local files,
including the stock config.yml and any variant affecting the current
host (which include role selectors, pair or host specific files).
The problem is that when pushing these to the remotes where the files
are local there, then their permissions will be fixed up, and that will
happen independently for different files on different nodes. Which
results in git conflicts when trying to merge back these files.
Instead add a new variable that contains the glob for all such
customized files which we will fix up in the current node.
Change-Id: Ib2a7317a92733ad5b4d2fa8106759b00049edb68
If the maintenance mode is enabled, then we shouldn't suggest to
run ngcpcfg build/apply, as this might cause unexpected side effects.
Instead report that the maintenance mode is enabled and we're skipping
checks.
Change-Id: I2ca43142a3caeac2c00514b1353568f4c438fbed
The configuration files specific to the ngcpcfg tool should not be
mixed with the site specific configuration, as that's rather confusing,
more so when the actual ngcpcfg configuration contains references to the
location of the ngcp-config dir itself, which makes it self-referential.
Change-Id: I93f59e2ce3441c2c315956f68e22e4b2e9c839ac
The HA_NODE, HA_FILE and HA_CONFIG variables and nomenclature are
deprecated in favor of the NGCP_NODENAME, NODE_FILE and NODE_CONFIG.
Switch the old uses to the new ones. Unify PAIRNAME to NGCP_PAIRNAME.
Leave the old HA_ variables for backwards compatibility
Change-Id: I11f09f1620c2e456f10fc17229b61ec5a35a732b
hook_setup() is called directly by some scripts
* fix test for apply: forcing changes in the repo in order to
have a commit message
Change-Id: I7da6f210826ae817b574bba793e61346ed6cac0d
Instead of checking for the user, group and mode configuration knobs in
various scripts (currently «build» and «set»), just make sure the
variables have sane defaults when loading the «ngcpcfg.cfg» file.
This also makes it possible to simplify the chown/chgrp calls into
single chown calls.
Change-Id: I1fcc06a7d311e4ebc4a96cc84ffae333be243c53
Executing something like this:
| root@web01a:~# touch /etc/ngcp-config/xz.yml
| root@web01a:~# ngcpcfg set /etc/ngcp-config/xz.yml ha.gcs=pacemaker
| [...]
| root@web01a:~# ngcpcfg commit "xz"
| root@web01a:~# DEBUG=1 ngcpcfg --debug push --nobuild --noapply
| [...]
This *might* result in merge conflicts, like:
| 2021-09-21 10:06:31 web01b: Pulling changes: 2021-09-21 10:06:31 web01b: Error: FAILED:
| interactive rebase in progress; onto ad0b99f
| Last command done (1 command done):
| pick 29bc5de /dev/fd/63 [2021-09-21 09:24:19.985891726+02:00]
| No commands remaining.
| You are currently rebasing branch 'master' on 'ad0b99f'.
| (fix conflicts and then run "git rebase --continue")
| (use "git rebase --skip" to skip this patch)
| (use "git rebase --abort" to check out the original branch)
|
| Unmerged paths:
| (use "git restore --staged <file>..." to unstage)
| (use "git add <file>..." to mark resolution)
| both modified: .ngcpcfg_perms
The underlying permission issue causing the megre conflict was fixed via
git commit 79ed4aa59 / Change-Id: I93017cdcdcf22fa1c5ef8e103d215aa7bc110b9a,
but regarding the "/dev/fd/63" - commit 29bc5de looking as:
| commit 29bc5debbe7e4015bcc689c828558d6a0420497b (HEAD -> master)
| Author: ngcp-config <root@web01b>;
| Date: Tue Sep 21 09:24:19 2021 +0200
|
| /dev/fd/63 [2021-09-21 09:24:19.985891726+02:00]
bash uses /dev/fd/63 in pipes (for sending results of process(es) to
another process). We don't want to end with `/dev/fd/63` in the commit
message during automatic merges like within `git pull --rebase` though.
This can be avoided by setting GIT_MERGE_AUTOEDIT=no.
Quoting from the Git v1.7.10 Release Notes:
| * From this release on, the "git merge" command in an interactive
| session will start an editor when it automatically resolves the
| merge for the user to explain the resulting commit, just like the
| "git commit" command does when it wasn't given a commit message.
|
| If you have a script that runs "git merge" and keeps its standard
| input and output attached to the user's terminal, and if you do not
| want the user to explain the resulting merge commits, you can
| export GIT_MERGE_AUTOEDIT environment variable set to "no", like
| this:
|
| #!/bin/sh
| GIT_MERGE_AUTOEDIT=no
| export GIT_MERGE_AUTOEDIT
|
| to disable this behavior (if you want your users to explain their
| merge commits, you do not have to do anything). Alternatively, you
| can give the "--no-edit" option to individual invocations of the
| "git merge" command if you know everybody who uses your script has
| Git v1.7.8 or newer.
Change-Id: Iafe5e4adb9afb9caf74d1ea81a208fdf608ddf54
Quoting the v7.0.2 changes from
https://github.com/koalaman/shellcheck/blob/master/CHANGELOG.md:
| SC1090: A leading `$x/` or `$(x)/` is now treated as `./` when locating files
So ShellCheck v0.7.2+ strips a single expansion followed by a slash,
e.g. "${FUNCTIONS}"/logs gets treated as './logs'. This allows usage of
source-path directives or -P flags to specify the a location, which is
what hereby enable in our shellcheck command line via `-P functions`.
We only need to disable SC1091 for sourcing "${FUNCTIONS}"/ha_features
and "${FUNCTIONS}"/carrier_features, as those files are part of a
separate, outside repository.
FTR:
* SC1090 = Can't follow non-constant source. Use a directive to specify location.
https://github.com/koalaman/shellcheck/wiki/SC1090
* SC1091 = Not following: [....]
https://github.com/koalaman/shellcheck/wiki/SC1091
Change-Id: Ibe72f0bb2fa64ea0f0a33c59fdbd4f45a7b1bf11
We are using console_output() from within log_info(), which is invoking
`console_output "$*\n"`, so we need to expand the escape sequences
(without interpreting other format specifiers), which is exactly what
"%b" provides in bash.
This is a fixup for previous commit 0dda93ad97
Change-Id: I16f354eb35e13568331e5107aff0d1c80dafb822
shellcheck v0.7.1 complains about a bunch of issues:
SC1083: This { is literal. Check expression (missing ;/\n?) or quote it.
SC1083: This } is literal. Check expression (missing ;/\n?) or quote it.
SC1090: Can't follow non-constant source. Use a directive to specify location.
SC2034: foo appears unused. Verify it or export it.
SC2059: Don't use variables in the printf format string. Use printf '..%s..' "$foo".
SC2128: Expanding an array without an index only gives the first element.
SC2148: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
SC2155: Declare and assign separately to avoid masking return values.
SC2162: read without -r will mangle backslashes.
SC2164: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
SC2207: Prefer mapfile or read -a to split command output (or quote to avoid splitting).
SC2237: Use [ -z .. ] instead of ! [ -n .. ].
We're still bound to support shellcheck v0.3.4 and sadly this version
fails hard when using the modern "shellcheck source=" directives to
address SC1090 and SC1091. It's failing like:
| not ok 1 source/functions/init:8:28: note: The mentioned parser error was in this then clause. [SC1009]
| not ok 2 source/functions/init:10:3: error: Couldn't parse this shellcheck annotation. [SC1073]
| not ok 3 source/functions/init:10:16: error: Unexpected "s". Fix any mentioned problems and try again. [SC1072]
So until we can get rid of supporting this ancient shellcheck version,
instead of using:
| # shellcheck source=etc/ngcp-config/ngcpcfg.cfg
| # shellcheck source=functions/init
| # shellcheck source=functions/logs
| # shellcheck source=functions/main
we need to place disable=SC1090 and disable=SC1091 accordingly.
Change-Id: I14da87a00102609bffdb60e932045180c6d13d5e
This makes it possible to use more specific config.yml files either for
a pair of nodes, for settings that will always affect both, or for the
HA names, for settings that might affect all A or B nodes.
This matches the support in the template files.
We need to move sourcing the ha_features and carrier_features before
sourcing init, as now the ngcpcfg.cfg file can use these variables if
set.
Change-Id: Ic6b32acceb8f020f48c3afa09d9e84252b3531e7
The current shell code is very inefficient, as it uses files to track
the file lists, and grep to traverse them NxM times per N files.
Change-Id: I8396b4ee232157cea8ef599cba0618be3dd93536
We need to call action and care about SUMMARY_ONLY without calling ngcpcfg.
main_action will be used in push-parallel to call pull/build/apply actions
directly without calling ngcpcfg. Also 'ngcpcfg push' can be migrated on new
approach '--remote' (recommended by Guillem Jover, BTW, Tnx!) from the current
approach of executing commands through ngcp-ssh on remote host.
Change-Id: I927b8055a040f49d6cfb462a200ad4d4b2d660ff
Sometimes (e.g. on 'push-parallel') we need to call ngcpcfg on
remote host and generating summary only output about the results.
It simplifies complex 'push-parallel' codebase which is critical
for huge Carrier installation.
P.S. we cannot print summary message all the time to console output,
as a lot of code depends on the ngcpcfg output, e.g.:
> root@web01a:~# ngcp-ppa gerrit_alutay_63758_push_parallel_2
> ERROR: There are uncommitted changes in config files:
> 2019-10-02 11:59:38 web01a: Successfully executed 'diff' on 'web01a'
> ERROR: Please commit them or discard
> root@web01a:~#
Instead, let's be backward compatible with printing on console,
but always print this message to log file (as we sometimes need to know
ngcpcfg exit code and it was impossible to find it in log file previously.)
Change-Id: I9aad0912796500cddb23d1f3eaa428b0b39152d0
About 50% of previous helper/build_config execution was loading 'functions/main'
and we were performing it again and again for every tt2 files we build
and we have more then hundred files in ngcpcfg.
In fact we need two env variables and logging functions.
Let's extract them into the separate function file and load them only.
Command: time ngcpcfg build
Original results: real 0m27.766s
Current results: real 0m19.976s
Change-Id: I6896ac437b1548888db7702de92b0ec79ed9d03f
Otherwise:
> warning: Brace expansions and globs are literal in assignments. Quote it or use an array. [SC2125]
Change-Id: I5a209cc1b50cea37e13aef40dfbd86c6178b53dc
We are performing complex manipulations with list of files to be build
to understand which tt2 file we should use: .tt2/customtt.tt2/tt2.sp1/...
In the same time 90% of our files has only .tt2, so let's check the count here
and use the $file if only one record is available to proceed.
Change-Id: Ib754390563a93a1fbdeb4a4147b066fcb53ed5cc
The previous code had three including loops:
- loop over all folders ${CONFIG_POOL}
- run find to get list of all files
- loop over all files in list
- check if no files requested (build all) then remember file
- loop over all requested files
- check if file was requested then remember file
- process further with all files we remembered above
The new logic is much simpler and faster:
- loop over all folders ${CONFIG_POOL}, remove missing
- run find on all available folders to get list of all files 'filelist_allfiles'
- check IF no files requested (build all)
- THEN just use all files from list 'filelist_allfiles'
- ELSE loop over all requested by user files (normally one/several)
- grep requested file from 'filelist_allfiles'
- process further with all files we remembered above
The two main ideas here:
- just use all files if we build all files, no need to loop one by one
- grep requested files from "all files" instead of searching them in loop
At the end we are 30% faster in case if we build one file only:
> Command: time ngcpcfg build /etc/default/ngcp-roles
> Old code: real 0m1.587s
> New code: real 0m1.060s
Change-Id: I206557b004ff95c0607150a61a9e6e743ab8cd29
These files are an intermediate data source, which are being used also
during builds of templates. We cannot make them first stage YAML sources
as they do depend on information coming from the first stage YAML
sources themselves. So we need to special-case them to make sure they
are always built first, so that the other files have up-to-date
information to use when being built.
Change-Id: I6cfd6e80823ddfaf71e2246de5518b9cb6d6a1d2
Otherwise ngcpcfg fails in trunk with error:
> +03:29:10 (cfg.inc:378): cfg_common_configuration(): ngcpcfg set /etc/ngcp-config/config.yml bootenv.netscript.fallbackfssize=10M
> Save size of 'code' partitions to /etc/ngcp-config/config.yml
> /usr/share/ngcp-ngcpcfg/functions//main: line 68: NGCP_TESTSUITE: unbound variable
Change-Id: I32961cda14550278662acd40ed5863c19412de3c
- Remove a spurious trailing ';'.
- Make the hook directory reaction conditional on whether we are running
from within a testsuite, to restore its otherwise fatal treatment.
Change-Id: I3f8a5364d7b2f0ac82bfdc132b94641603225f85
Fixes: commit 505d6566d8
Unfortunately git doesn't track POSIX file permissions,
which cause perms drop on some git commands like 'git stash/pull/reset', etc.
We must be sure 'restore-permissions' always executed at the end of 'ngcpcfg'.
Also we must be sure we update .ngcpcfg_perms whenever we start 'ngcpcfg',
otherwise we might loose not-yet committed changes in .ngcpcfg_perms.
Example during the upgrade mr7.0->mr7.1:
1) JFYI, ngcpcfg mr7.1+ copies perms from source tt2 file to the destination config
2) on mr7.0->mr7.1, ngcp-upgrade installs new package ngcp-templates-pro package
with new perms on tt2 files (which are not committed by apt as /etc/ngcp-config
is not covered by 'etckeeper', it is by design).
3) later ngcp-upgrade executes 'ngcpcfg build' to build some config.
4) on PRO/Carrier 'ngcpcfg build' executes 'ngcpcfg pull' first to
ensure there is no outstanding changes on shared git repo
(has been done on Ops request in MT#15803).
5) 'ngcpcfg pull' does 'git stash/pop' before pulling which effectively
reset new perms which came from package in step 1 (as git doesn't track
perms on files, by design).
Summary/fix:
whenever we stash something we should ensure perms are stored as well,
which means we need to generate new .ngcpcfg_perms and store it in stash
together with all the rest local changes.
Change-Id: I5292d4433a39ff2751874d63083f093f19b9cfe2
When running the test suite, in case we need to cover the code paths
that are handling the hooks, we should not assume the files are
installed in the system directories.
Change-Id: I1cd09eaf186d28093eb03ad5e9fc096fe7d63a3e
'git status' output has been changed in 2.9 which causes some troubles for us
(we didn't change all the places, we missed ngcpcfg-ha.git repo,
better to use common code in all the places).
Change-Id: Ie664af89ee6d6b31fb3011e763107c41bf4cf00f
The night Carrier trunk installation has failed:
> +02:29:59 (cfg_pro.inc:280): cfg_ngcpcfg_init_mgmt(): cfg_ensure_file_mgmt_node
> ...
> +02:29:59 (cfg_pro.inc:282): cfg_ngcpcfg_init_mgmt(): '[' -x /usr/share/ngcp-ngcpcfg/scripts/init-mgmt ']'
> +02:29:59 (cfg_pro.inc:287): cfg_ngcpcfg_init_mgmt(): DEBUG=yes
> +02:29:59 (cfg_pro.inc:287): cfg_ngcpcfg_init_mgmt(): /usr/share/ngcp-ngcpcfg/scripts/init-mgmt
> /usr/share/ngcp-ngcpcfg/functions//main: line 18: HNAME: unbound variable
The manual execution of script 'init-mgmt' shows no error,
so far if 'DEBUG=yes' is enabled the issue is easily reproducible.
The reason here is debug messages which can be printed on the
very early stage of initialisation and cause the issue here:
> ++ log_debug 'sourced configuration file /etc/ngcp-config/ngcpcfg.cfg'
> ++ '[' -n yes ']'
> ++ logger -t ngcpcfg -- 'Debug: sourced configuration file /etc/ngcp-config/ngcpcfg.cfg'
> ++ console_output 'DEBUG: sourced configuration file /etc/ngcp-config/ngcpcfg.cfg\n'
> ++ '[' -z '+%F %T' ']'
> +++ date '+%F %T'
> ++ local 'timestamp=2018-10-12 10:16:24'
> +++ printf -- '%s: ' '2018-10-12 10:16:24'
> +++ sed 's/./ /g'
> ++ timestamp_replacementchars=' '
> /usr/share/ngcp-ngcpcfg/functions//main: line 18: HNAME: unbound variable
Let's be polite for such kind of log message.
Change-Id: I3647567aba5fad3a103af2e6da35229f6d932bed
It is necessary to improve navigation into long 'ngcpcfg push all'
output on huge customer's systems. Requested by Sipwise Ops team.
Previously:
2018-10-11 10:48:40: Generating /etc/update-motd.d/05-maintenance-mode: OK
2018-10-11 10:48:40: Executing postbuild for /etc/update-motd.d/05-maintenance-mode
2018-10-11 10:48:40: Generating /etc/update-motd.d/10-heartbeat: OK
2018-10-11 10:48:40: Executing postbuild for /etc/update-motd.d/10-heartbeat
2018-10-11 10:48:40: Generating /etc/update-motd.d/20-sysinfo: OK
Now:
2018-10-11 11:55:28 web01a: Generating /etc/systemd/system/redis-server.service: OK
2018-10-11 11:55:28 web01a: Generating /etc/systemd/system/rsyslog.service.d/override.conf: OK
2018-10-11 11:55:28 web01a: Generating /etc/systemd/system/slapd.service.d/override.conf: OK
2018-10-11 11:55:28 web01a: Generating /etc/systemd/system/slapd.service: OK
2018-10-11 11:55:28 web01a: Generating /etc/systemd/system/snmpd.service.d/override.conf: OK
Change-Id: I3035293b95f64033005cc5f8d031dbbfac1dcc33
The 'ngcpcfg' received support for 'patchtt' files, like
> /etc/ngcp-config/templates/etc/foo/bar.patchtt.tt2
Those 'patchtt' are going to be applied on default 'tt2 template' file:
> /etc/ngcp-config/templates/etc/foo/bar.tt2
and produce 'customtt' on 'ngcpcfg patch':
> /etc/ngcp-config/templates/etc/foo/bar.customtt.tt2
Further 'customtt' will be used to overwrite 'tt2 templates'
on 'ngcpcfg build' or 'ngcpcfg apply'.
NOTE: 'ngcpcfg patch' is executed automatically on every 'ngcpcfg build'.
It should allows to update ngcp-templates easily and support
local modifications without the pain (until the patches can be applied).
Change-Id: Ice4369386313c5d33e4d498346345eade6f3d0d7
The old testsuite wasn't updated for way too long and since
ngcpcfg receives more and more features we need a decent test
coverage. pytest seems to provide the right level of
abstraction, excellent fixtures and junit-xml reporting as
needed.
Inspired by Vincent Bernat's
https://github.com/vincentbernat/lldpd/tree/master/tests/integration
Thanks Victor Seva <vseva@sipwise.com>, Vincent Bernat <vincent@bernat.im>, Christian Hofstaedtler <christian@hofstaedtler.name> and Lukas Prokop <admin@lukas-prokop.at> for feedback, inspiration and help
Change-Id: Iffed87e8cc540169bed89c00967a03e80859179e
If we have multiple web0X proxies but need specific
templates on just one of those pairs then we need to
support *.customtt.tt2.$pairname + *.tt2.$pairname
templates.
While at it also support *.customtt.tt2.$nodename +
foo.tt2.$nodename (where nodename is actual hostname
and not sp1 or sp2 as already supported already).
Test script for demonstration (especially for precedence):
mkdir /etc/ngcp-config/templates/etc/mika
cd /etc/ngcp-config/templates/etc/mika
hostname=$(hostname) # e.g. web01b
pairname=${hostname%[ab]} # e.g. web01
nodename=$(cat /etc/ngcp_nodename) # e.g. sp2
for file in foo.customtt.tt2.$hostname foo.customtt.tt2.$pairname foo.customtt.tt2.$nodename foo.customtt.tt2 foo.tt2.$hostname foo.tt2.$pairname foo.tt2.$nodename foo.tt2 ; do echo $file > $file ; done
for file in foo.customtt.tt2.$hostname foo.customtt.tt2.$pairname foo.customtt.tt2.$nodename foo.customtt.tt2 foo.tt2.$hostname foo.tt2.$pairname foo.tt2.$nodename foo.tt2 ; do
ngcpcfg build /etc/mika/ >/dev/null
if [ "$(cat /etc/mika/foo)" = "$file" ] ; then
echo "Content of file /etc/mika/foo matching $file"
rm "$file" ; rm /etc/mika/foo
else
echo "Problem with precedence of file $file"
return 1
fi
done
Change-Id: If7c222374bb56d7bf243200b37a414e39e050cd4
Git doesn't track file permissions (except for the executable
flag). For sensitive data (like the 'ssl' directory and file
'constants.yml' with passwords included) we've to prevent
non-root users from accessing those files.
hooks/pre-commit is inspired and based on the implementation
as present in etckeeper (and luckily we're license compatible)
and takes care of storing the file permissions inside file
/etc/ngcp-config/.ngcpcfg_perms.
The restore-permissions helper script takes care of restoring the
permissions after cloning the ngcpcfg repository via ngcpcfg
itself (being actions decrypt, pull (PRO-only) + initialise
(PRO-only)). It can be executed manually as well via
`usr/share/ngcp-ngcpcfg/helper/restore-permissions /etc/ngcp-config/`
(or wherever the according ngcpcfg repository is placed at).
Regarding the commit integration: git(1) itself doesn't track
file permissions, so we can't detect changes to file permissions
using git itself. Our new pre-commit hook records file
permissions via the .ngcpcfg_perms file. Now by just invoking it
during 'ngcpcfg commit' time we can ensure that even if there
have been any file permission changes in the working directory
the file .ngcpcfg_perms is then up2date and committed.
JFTR: The solution via the git pre-commit hook ensures that no
matter whether you're using 'ngcpcfg commit …' or 'git commit …'
you always get the file permissions handled via .ngcpcfg_perms.
Now if you want to change file permissions in a clean working
directory and commit *without* using 'ngcpcfg commit' but
directly via git itself then you've to use 'git commit
--allow-empty ...' and thanks to the pre-commit hook the file
.ngcpcfg_perms will still be up2date.
Change-Id: I84d608585c626b52112ff649893e232e441c59d8
Verify that the user is operating on branch master,
otherwise the result might be unexpected.
If branch master is checked out:
| root@spce:/etc/ngcp-config# ngcpcfg check
| root@spce:/etc/ngcp-config# ngcpcfg status
| [...]
| 2016-02-23 05:48:32: Checking currently active branch:
| 2016-02-23 05:48:32: OK: branch master active
If a branch other than 'master' is checked out:
| root@spce:/etc/ngcp-config# ngcpcfg check
| 2016-02-23 05:47:42: Error: branch 'mika' in '/etc/ngcp-config' active - please switch to branch 'master' before continuing.
| root@spce:/etc/ngcp-config# echo $?
| 1
| root@spce:/etc/ngcp-config# ngcpcfg status
| [...]
| 2016-02-23 05:47:47: Checking currently active branch:
| 2016-02-23 05:47:47: ACTION_NEEDED: branch 'mika' active - please switch to branch 'master'
| [...]
Change-Id: I5df92075905cafa3b714211581c8cfe749df04ba
In a previous implementation using timestamps we ran into timing
problems on slower systems. So instead lets record the git commit
ID of the latest ngcpcfg commit and check whether we have a match
between this commit and an according ngcpcfg build.
If the "ngcpcfg build" was executed without an "ngcpcfg commit"
before then we mark it as dirty since we don't have an according
git commit available for testing against. Since that's a common
workflow we don't report it as a real problem though, instead we
inform the user using:
| OK: nothing to build (latest build newer than latest commit)
As we commit AFTER the build in the apply action we can use a
workaround for this situation, so build and commit state match
with each other in that case then.
Change-Id: I48e32db6f42b53fe97a0b88805e7ddbee8576133
Guillem Jover
Mykola Malkov
Michael Prokop
ngcp-config
Alexander Lutay