The point of these tests originally was to verify the proper location
of a log file. Checking return codes is just spurious and ties the test
too closely with the shutdown behavior of the daemons which are tracked and tested
in other places more closely and with more accuracy.
Since all pieces of the GrainsAppendTestCase are destructive, let's
just wrap the whole class test case.
Because the tests themselves as well as the `tearDown` function were
wrapped in a @destructiveTest decorator, some test errors were printing
in the test output when --run-destructive isn't passed at the CLI.
This fixes those test errors.
We have a couple of tests using the "assert_called_once" function, however, our salt-jenkins
states pin the version of mock at 1.0.1 (This is the last version that is compatible with
Python 2.6). We either need to use something else that works for all versions of mock or gate
the test.
In the pacman tests, it is possible to use "assert_called_with" instead of "assert_called_once"
In the dimension_data and gce unit tests, we need to gate the assertion behind a mock version check.
This way the tests won't fail if the version of mock installed is less than 2.0.0.
The test that runs these states is testing for behavior that was
obsoleted by virtualenv 13.0. Ensure that we have older virtualenv
available, and then create a venv with that older version. Use the
2nd virtualenv to attempt the "weird" install.
* git.latest: fail gracefully for misconfigured remote repo
When the remote repo's HEAD refers to a nonexistent ref, this was
causing a traceback when we tried to check if the upstream tracking
branch needed to be changed after cloning the repo. This commit fixes
this traceback by gracefully failing the state when the remote HEAD is
not present in the ``git ls-remote`` output, but the desired remote
revision doesn't exist.
Additionally, a similar graceful failure now happens if the state is run
again after we gracefully fail the first time, and we need to set the
tracking branch. Trying to set the tracking branch when there is no
local branch would fail with an ambiguous error like "fatal: branch
'master' does not exist", so before we even attempt to set the tracking
branch, the state is failed with a more descriptive comment.
* Add integration test for #36242
When using `fopen`, we need to import all of salt.utils. We should
also be explicit about calling salt.utils.fopen.
This also cleans up the ordering of the salttesting vs salt libs to
be consistent with other files and conform with `ensure_is_syspath`.
Also changes a print statement to a log.info
This update allows granting privileges on ALL tables or ALL sequences
in a given schema. Such as:
GRANT SELECT ON ALL TABLES IN SCHEMA public TO 'monkey';
* Quote postgres privilege target names
Postgres lets you put characters in table/database names which you then must
quote. So we should always quote.
* Updating unit tests
* Also quote role names.
Role names can also have dashes (or others) in them, so we must also quote
them.
The blockdev module is being slowly deprecated and its functions moved to
to the disk module instead. There is a test for resize2fs in the blockdev_test
file in the 2015.8 branch (which matches the resize2fs function in the blockdev
module), but this function was moved to the disk file in 2016.3. The test was
never moved over.
I discovered this during a merge forward in #36344. This PR adds the
test from 2015.8 blockdev_test to the 2016.3 disk_test.py, and is adjusted
to work with the disk module accordingly.
The test that runs these states is testing for behavior that was
obsoleted by virtualenv 13.0. Ensure that we have older virtualenv
available, and then create a venv with that older version. Use the
2nd virtualenv to attempt the "weird" install.
* Fixing integration tests if azure is not present
* Fixing integration tests failures if 'git' command is missing
Skip git state integration tests if 'git' does not exists
Prevent OSError if 'git' command not found during _git_version()
The test suite actually has a ``prod`` env, but this test only considers
the ``base`` env. If a test is run which requests a file (or just the
file/dir/symlink/... list) from the ``prod`` env, then this will result
in the ``prod`` env's file list caches being present, and they will be
removed when the ``fileserver.clear_file_list_cache`` runner is
executed, showing up in the return data and causing the test to fail.
This tweak to the test ensures that we will always have a file list
cache for ``prod`` present, and adjusts the necessary asserts in the
test to expect the ``prod`` env in the return data from the runner.
* Fix PillarModuleTest::test_pillar_items: 'info' does not exist in pillar
* Fixing integration tests if azure is not present
* Fixing integration tests failures if 'git' command is missing
Skip git state integration tests if 'git' does not exists
Prevent OSError if 'git' command not found during _git_version()
The tests that return files, symlinks, directories, and empty dirs were
all only testing that the type of the return data was the same as what
was expected. By not testing the content, we overlooked a corner case in
which backends passed into the fileserver as a Python list would not be
handled properly. This has since been fixed in PR #36244, but these
tests will help keep this sort of issue from regressing.
When parallels creates linked clones, it generates a new snapshot on the
cloned VM with the name 'Snapshot for linked clone', which when used
with jenkins results in hundreds of unneeded snapshots per week.
* Fix signal handling
We had a little mix-up with the args ordering for our signal handling.
This sends the proper signal to processes on cleanup.
I have also temporarily disabled the pytest engines because they were
causing the minions to try to to connect to a master IPC socket which could not be found.
This put the minions into a continual futex state which was not playing well with kill sigs.
* Lint
Trying to assert that an exception was raised using
helper_open.write.assertRaises() is bogus--there is no such method. Use
standard unittest.assertRaises() instead.
Trying to assert that an exception was raised using
helper_open.write.assertRaises() is bogus--there is no such method. Use
standard unittest.assertRaises() instead.
These tests have never run automatically because of an incorrect file name.
Added a skipIf on these tests as they are currently non-functioning and the
module they're testing has been deprecated.
