| Age | Commit message (Collapse) | Author |
|---|
|
'non-repository' at the path. That can be even just an empty directory. This
makes it so further puppet runs cannot ever complete properly, because of this
error:
change from absent to present failed: Could not create repository (non-repository at path)
This requires manual intervention to resolve (ie. removing the directory).
It is possible to pass the 'force => true' parameter to vcsrepo to handle this,
however, all this will do is remove whatever is there, even if it is a valid
repository. That means on every puppet run you get the tree removed and then a
new clone is done. This is less than ideal for a number of reasons.
So this commit adds a test to determine if the location contains a valid
repository and then it is used when 'force => true' to determine if it should
replace the existing content with a fresh clone.
Note: the valid_repo? check is also added to the 'def bare_git_config_exists?'
because the test that is done there is intended to look for a bare git
repository by checking to see if there 'config' is in the directory. This isn't
a particularly robust test because 'config' could be in a directory, when it
isn't a bare git repository (such as is common in a rails app) causing vcsrepo
to mistakenly think it was a proper bare repository, when it isn't.
|
|
SVN provider should check for '^Revision:' and not '^Last Changed
Rev:'. Addresses GitHub Issue #43.
|
|
|
|
added checks that the URL of the WC matches the URL from the manifest
changed from using "update" to "switch"
|
|
|
|
|
|
|
|
Pull request related to issue #8331.
I have added support into the exists? method (actually working_copy_exists?) for checking if the path is a master repository, using svnlook. It should be ok in most cases, since svnlook comes with svnadmin in nearly every distribution.
|
|
|
|
|
|
|
|
|
|
|
|
Enable unlimited nesting for submodule updating
|
|
fix git provider checkout of a remote ref on an existing repo
|
|
Per discussion of https://github.com/puppetlabs/puppetlabs-vcsrepo/issues/51 in
the git channel on freenode, EugeneKay <eugene@kashpureff.org> stated that `git
rev-parse` is not capable of inspecting remote refs but that `git ls-remote`
is. This patch makes a second attempt to resolve the ref with `ls-remote` if
`rev-parse` fails.
The git provider also appears to support several type features that are not
tagged under `has_features`. It's not clear if this is the best way to resolve
this issue or if the provider should be refactored to work with different type
features.
Demonstration of the problem with changing refs (branches and tags)
$ git --version
git version 1.7.1
$ cat master.pp branch.pp
vcsrepo { '/tmp/vcsrepo':
ensure => present,
provider => git,
source => 'https://github.com/puppetlabs/puppetlabs-vcsrepo.git',
revision => 'master',
}
vcsrepo { '/tmp/vcsrepo':
ensure => present,
provider => git,
source => 'https://github.com/puppetlabs/puppetlabs-vcsrepo.git',
revision => 'feature/cvs',
}
$ puppet apply --modulepath=`pwd`/.. master.pp
Notice: /Stage[main]//Vcsrepo[/tmp/vcsrepo]/ensure: Creating repository from present
Notice: /Stage[main]//Vcsrepo[/tmp/vcsrepo]/ensure: created
Notice: Finished catalog run in 2.19 seconds
$ puppet apply --modulepath=`pwd`/.. branch.pp
Error: /Stage[main]//Vcsrepo[/tmp/vcsrepo]: Could not evaluate: Execution of '/usr/bin/git rev-parse feature/cvs' returned 128: fatal: ambiguous argument 'feature/cvs': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
feature/cvs
Notice: Finished catalog run in 1.69 seconds
|
|
|
|
|
|
hg_with_identity function renamed to hg_wrapper. Added ability to specify a user and an SSH identity.
Added extra options to the ssh command.
Identity and user fixed
Requirement for pp deleted.
|
|
|
|
Handle force in svn args
|
|
"ensure => latest" support for bzr
|
|
other remote connection issues) from blocking the Puppet run
|
|
|
|
Tighten regex to avoid matching the word 'commit' in message
|
|
Allow non-root users to clone a repo
Merging my own PR because it's just a rework of an existing PR.
|
|
Without this, git will report that it can't change back to /root
|
|
|
|
Update origin if necessary before checking revision
This looks good. Thanks!
|
|
|
|
|
|
|
|
|
|
Conflicts:
lib/puppet/provider/vcsrepo/cvs.rb
spec/support/fixture_helpers.rb
spec/unit/puppet/provider/vcsrepo/cvs_spec.rb
|
|
|
|
|
|
Removes trailing whitespace
|
|
Add default user to run git as.
|
|
warning about multiple default providers for :vcsrepo.
|
|
The last merge: 4d2942edc26e7cd144a3178a1a7f6470ea401345 brought some
regression that this patch should hopefully fix.
Firstly, the tool no longer supported updating a branch as the syntax for git
pull on anything but a branch was invalid.
This also removes the extra call to 'checkout' which was causing behaviour
to occur without notifying puppet, thus causing subscription notifications
to not fire.
|
|
|
|
Add a default to the user parameter of root, which is the user that
the git commands would have ran in previously versions of this module.
Without this an upgrade to the lastest release would cause syntax
error all over a person's code base and provide no benefit.
|
|
options to ensure no prompting (also fixed in pull request #1 by riseuplabs), added ability to keep repository up to date with latest (puppetlabs ticket 11278)
|
|
Add the ability to specify a git remote
|
|
Rather than fill the git provider with hard-coded references to
origin, it would be better to abstract out which remote the resource
is fetching from. But since this is only relevant to decentralized
version-control systems, a multiple_remotes feature was added for
the parameter to depend on. So far this is only implemented for git
remotes, but it could be implemented for other VCSs as well.
|
|
changes are found; this change gets reverted in mercurial 2.1.1)
|
|
|
|
The git provider had some problems checking out SHA1s - it couldn't.
And what's worse, it lied about what it was doing saying that it did
checkout the SHA1.
There was also a bug where if you specified a different branch than you
were on, it was doing a `reset --hard` to the specified branch. For
example, if master was checked out, and you set "revision => stable", it
would `git reset --hard stable` on the master branch instead of just
checking out stable. Maybe the original author did this to get around
being unable to checkout when you had local changes, but the --force
flag to checkout will fix that.
With this change, you should now be able to specify a branch, tag, or
SHA1 in the revision attribute and have it work.
|
|
Fix (#10787) - Various fixes/tweaks for the CVS provider
|
|
Fix (#10788) - Avoid unnecessary remote operations in the vcsrepo type
|
