This fails on centos 6 because its node is too old to support the version of
hawk bumped here https://github.com/request/request/pull/2751, we can still
test the functionality. This will pull from github, and install a specific tag
version, and we still do the uninstall using the github path.
This should be more stable.
At this moment when you post more than one statement in config only last
is used. Also file is rewrited multiple times until last statement is
written.
Example:
salt '*' apache.config /etc/httpd/conf.d/ports.conf config="[{'Listen': '8080'}, {'Proxy': "Something"}]"
Ends only with
Proxy Something
and ignore Listen 8080,
This patch fix this issue.
This catches the (expected) CommandExecutionError when git.describe is
run on a commit that doesn't exist.
This also renames the remote_ref_type variable to remote_rev_type. This
change was made for the 2017.7 branch, but this fix is being applied to
2016.11, so by making the rename here as well we will avoid a potential
bug from creeping in on a merge-forward.
Forking the systemd-notify command is known to be unreliable at least
with older versions of the kernel and/or systemd. When systemd receives
the notification the systemd-notify process may have already exited
causing an error in the logs while waiting for a (90 seconds) timeout.
This patch instead notifies the systemd NOTIFY_SOCKET synchronously in
case the systemd.daemon python library is not available.
The Testinfra module had a line where the collection of passed arguments was silently overwritten so that it would not actually perform any assertions. Updated the variable names to address the issue of the parameters being clobbered so that asertions are performed properly.
The git.latest state runs a `git ls-remote` on the remote repo to
discover which SHA it should end up at, and whether or not it needs to
fetch from the repo to get the commit it needs. However, since we
fast-forward using a `git merge` to the branch specified in the `rev`
argument, this leaves the state susceptible to a race condition when
someone pushes to the remote repo between when we run the `git
ls-remote` and when we fetch the remote repo. We will successfully
fast-forward to the head of the branch, but that branch will be pointing
to a different commit than the one identified in the `git ls-remote`, so
we will report the state as having failed.
This commit fixes that race condition by fast-forwarding to the commit
identified in the `git ls-remote`, rather than to the branch named by
`rev`.
NOTE: This means that in these edge cases, we will report a `True`
result despite the head of the branch having advanced past the commit to
which we fast-forwarded, but that seems like a reasonable trade-off for
avoiding a race condition. If we repeated the `git ls-remote` after
fetching, we'd just be opening up a window (albeit a smaller one) for
another race condition.
