If the module directory is not writable/executable to the current user
(most likely because of a sudo to a non-root user), the ssh_wrapper
will be created in the default location for mkstemp() calls. To facilitate
the deletion of these new files, a new mechanism for cleaning up files
created by the module was also added.
Fixes#7375
This simply adds --remote to the git submodule update command.
This means that if a branch is defined in .gitmodules then we should track said branch when updating.
hostnames in the known hosts file are typically stored as Hashed values, calling 'ssh-keyscan' with '-H' changes to output to the Hashed format so that the known_hosts file looks more consistent
* Adds another module utility file which generalizes the
access of urls via the urllib* libraries.
* Adds a new spec generator for common arguments.
* Makes the user-agent string configurable.
Fixes#6211
There is a subtle bug in how the git module currently works. If the
version you request is a tag name, and you've already got the repo
cloned, and the tag name is a new tag, but refers to the already checked
out working copy, the git module would exit early without change. This
is bad as it means the new tag ref was not fetched and could not be used
in later tasks.
This change will check if the version is a remote tag, and if the tag
doesn't exist locally. If that is true, it'll do a fetch.
The activity could still be seen as not a change, because the working
copy won't be updated, if the new tag refers to the already checked out
copy, but that's not different than before and can be fixed as a more
comprehensive overhaul of tracking change in the git module.
There is a bug in the `hg` module where if a `tag` is used it won't
properly be able to update to it.
This problem is exhibited on repository where a tag is moved from an
older commit to a newer commit.