These tests were failing because of improper mocking. The mocks were
assigned to the __salt__ dunder but we should have been patching the
attributes of the docker execution module directly.
These dunders are already being mocked appropriately below in the test, so we
don't need to define them in the test module's namespace.
The global definitions here were conflicting with the globals defined in
`saltmod_test.py`, and causing the following stacktrace in the test suite:
```
Traceback (most recent call last):
File "/root/SaltStack/salt/tests/unit/saltmod_test.py", line 71, in test_state
self.assertDictEqual(saltmod.state(name, tgt, highstate=True), test_ret)
File "/root/SaltStack/salt/salt/states/saltmod.py", line 252, in state
masterless = __opts__['__role'] == 'minion' and \
KeyError: '__role'
```
The type of the ``path`` value changed in #38188.
This updates the type in the unit test, as well as rearranges some
of the imports to be more standardized with ``ensure_in_syspath``.
The previous way this test was written was over-mocking some of the
state returns as well as tested and asserted against incorrect
behavior as shown in issue #39255. (The test asserted that a return
of '' from the call to _checkblk() was correct, which was hiding a
bug as noted in #39255 and fixed in #39272.)
* Add config params for custom refspecs
* Add exceptions for errors encountered modifying git config
* Make the refspecs a configurable parameter
* Make refspecs a per-remote parameter
* Update master config template to include custom refspecs opts
* Add documentation for new config params
* Update GitFS walkthrough with a section on custom refspecs
* Remove dulwich support from salt.utils.gitfs
Dulwich still lacks important features, including (but not limited to)
the following:
- Lack of the necessary support for checking out a ref needed for
git_pillar/winrepo support
- No support in its config objects for multivar git config items, making
it impossible to detect when repos have multiple refspecs set for a
given git remote
Given this information, and the fact that it trails as a distant third
to Pygit2 and GitPython, Salt will cease to support Dulwich as a git
interface moving forward.
* Excise references to dulwich from documentation
* Add mention of custom refspecs to Nitrogen release notes
* Add gitfs_refspecs to mocked opts in gitfs integration tests
Also remove dulwich from unit tests
* Add information about opts argument not being intended for CLI use
Version 2.6.0 changed the wording of one of the exceptions tested,
causing tests to fail when jsonschema 2.6.0 is installed. This commit
updates the tests to change the assert for 2.6.0 and later.
* Fix for #38697
* Lint fixes
* Added missing source_hash_name argument in get_managed function
Additional fix to #33187
Customer was still seeing errors, this should now work.
Tested with 2015.8.13 and 2016.11.2
* [2016.3] Pylint fix (#39202)
* Ignore empty dicts in highstate outputter
Closes#37174
* Sort the return list from the fileserver.envs runner
* Fix the win_ip_test failures (#39230)
The changes made in #38793 changes the "get_all_ointerfaces" call
to be a list of DNS servers. This change adjusts the tests structure
from a string to a list and fixes the test failure.
The changes made in #38793 changes the "get_all_ointerfaces" call
to be a list of DNS servers. This change adjusts the tests structure
from a string to a list and fixes the test failure.
Stabilizes these tests by avoiding errors when cheese, crackers
order changes in the comment and gives errors like:
- 'comment': 'Kernel modules crackers, cheese are already present',
? --------
+ 'comment': 'Kernel modules cheese, crackers are already present',
? ++++++++
* Don't abort pillar.get with merge=True if default is None
This prevents a SaltInvocationError from being raised if the default is
loaded from a import_yaml jinja macro and the file being loaded is empty
(which is an entirely valid use case). In these cases, the loaded
default would be None, which we don't want to cause an exception.
* Add test case for issue 39062
If all the devices submitted to pvcreate() are already initialized as
LVM physical volumes, pvcreate() should return True and no futher
actions should be made.
pvdisplay() would be called by pvcreate() twice: firstly to check
whether a device is already initialized for use by LVM and then to
ensure that the pvcreate executable did its job correctly. The test
replaces pvdisplay() with a mock that always returns True and thus
pvcreate() would think that a specified device is already initialized
and exit. In the other words, instead of testing physical volume
initialization the test simulates a case with all the submitted
devices already initialized.
Fix it by replacing pvdisplay with a mock that returns False on the
first call (thus pvcreate thinks that a device is not a PV yet) and True
on the second call (after the pvcreate executable is called).
'lvm version' produces multiline output whereas test_version and
test_fullversion use mocks with single-line output. Use real-life
'lvm version' output in those mocks instead.
* openvswitch: add a basic unit test for openvswitch
* openvswitch: enclose comments_* variables into a map
* openvswitch: only prepare error messages if type parameter is present
* openvswitch: add test case: create a GRE port
* openvswitch: remove trailing whitespace
* openvswitch: add missing "comments" variable
* openvswitch: pep8 compliance
* openvswitch: mock dig.check_ip
* openvswitch: rename "type" argument into "tunnel_type"
* openvswitch: reference bridge_exists before assignment
* openvswitch: reference port_list before assignment
* openvswitch: add upgrade note about "type" option renaming
These unit tests exposed a bunch of python 3 incompatibilities in the
filebuffer util as well as the find util. The filebuffer changes should
be reviewed carefully.
Once this happens, we need to re-enable the test. The move over
should also allow us to upgrade the version of salt-testing that
is applied to the test VMs. Once this is complete, we can apply
the `@flaky` decorator to this test. (salt-testing must be a
version newer than the September release.)
Allows this code path to succeed for a minimal roster file that does not
specify `ssh_options`
$ sudo salt-ssh 'login1*' test.ping
Permission denied for host login1, do you want to deploy the salt-ssh
key? (password required):
[Y/n] Y
Password for root@login1:
login1:
True
