This test is testing an old version of virtualenv with pip_env, and the version
of pip is 6.x.x, which is too old and doesn't work with the importlib in python
3.6. Skipping this test if python is newer then 3.5.
This makes the following changes:
- The `append_newline` argument to the `file.blockreplace`
remote-execution function has been modified so that if its value is
`None`, it only appends a newline when the content block does not end
in one.
- A couple of fixes were made to newline handling. The existing code
normalized the newlines in the content block, replacing them with
os.linesep. However, when the file contains newlines that don't match
the OS (i.e. POSIX newlines in a file on a Windows box, or Windows
newlines on a Linux/Mac/BSD/etc. box), then we would still end up with
mixed newlines. The line separator is now detected when we read in the
original file, and the detected line separator is used when writing
the content block. Additionally, the same newline mismatch was
possible when appending/prepending the content block. This has been
fixed by using a common function for appending, prepending, and
replacing the content block.
- Support for the `append_newline` argument has been added to the
`file.blockreplace` state. The default value for the state is `None`.
A `versionchanged` has been added to the remote execution function to
let users know that the Fluorine release will change the default value
of that variable.
- 20 new integration tests have been written to test the
`file.blockreplace` state.
pip.installed state calls pip.freeze to check for existing installation
and to verify installation post-install. This patch propagates the
env_vars passed to pip.installed to the pip.freeze function. It also modifies
existing pip unit tests to test new functionality and adds an integration test
that verifies the expected correct behavior
Fixes#46127
The logic which ensures that we expose ports which are being bound,
even when not explicitly configured, was done incorrectly. UDP ports
were being passed to the API as '1234/udp' instead of (1234, 'udp').
This results in the port not being exposed properly.
The logic has been corrected. Additionally both the "ports" input
translation function, as well as the post-processing code (where the
port numbers configured in port_bindings were being added) both
contained code to "fix" any ports which were configured using
'portnum/tcp', as these must be passed to the API simply as integers. To
reduce code duplication, this normalization is now only performed at the
very end of the post-processing function, after ports have been
translated, and any missing ports from the port_bindings have been
added.
The unit test for the port_bindings input translation code, which was
written based upon the same incorrect reading of the API docs that
resulted in the incorrect behavior, have been updated to confirm the
(now) correct behavior. The unit test for the ports input translation
code has been updated to reflect the new normalization behavior.
Finally, an integration test has been added to ensure that we properly
expose UDP ports which are added as part of the post-processing
function.
the running tests run second because of alphabetical order, and stopping sshd
does not kill off the running connection, so we know that sshd has to be on
arch for us to connect, so stop it with dead and start it back with running.
It is also not possible to stop the systemd-journald process without shutting
down the full machine.
Carbon 1.1.1 for some reason added six to their setup.py, which breaks
this test since it's not installed into the virtualenv. This PR forces
this test to use a version of carbon which does not dep on six in its
setup.py.
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.
This is the error
```
npm ERR! As of npm@5, the npm cache self-heals from corruption issues and
data extracted from the cache is guaranteed to be valid. If you want to make
sure everything is consistent, use 'npm cache verify' instead.
npm ERR!
npm ERR! If you're sure you want to delete the entire cache, rerun this command
with --force.
```