Age | Commit message (Collapse) | Author |
|
The git_clone_protocols_spec.rb will be used to enumerate over the
available protocols for git to use to clone to disk. Support
key files are also included for https/ssl use.
Protocols tested
* file protocol (raw filepath)
* file protocol (file://)
* git protocol (git://)
* http protocol (http://)
* https protocol (https://)
* ssh protocol (ssh://user@host)
TODO: Currently, the ssl cert is not added to the CA on the host.
This causes the git clone to fail because the cert is not trusted
and the client does not proceed with a non-trusted ssl connection.
|
|
|
|
This adds support for beaker-rspec as well as basic test coverage for git
|
|
When using the following sample, the provider does not use the value of remote
when cloning a repository:
vcsrepo {'/path/to/repo':
ensure => 'present',
provider => 'git',
remote => 'test',
source => 'git@somerepo:repo.git',
}
$ git remote
origin
This commit makes sure that the new repository has a remote with the
supplied value.
Closes #MODULES-430
|
|
The new parameter used to indicate that you want a shallow clone is `:depth`
|
|
This commit also contains git provider `latest' method formatting changes;
squashed by request.
|
|
|
|
|
|
convert_bare_to_working_copy
|
|
|
|
Also add some fixtures for previous tests.
|
|
This work gets rid of the provider_example_group and reworks everything
to work properly against rspec2. I don't know if I'd consider the style
"better" but it works.
|
|
|
|
|
|
|
|
|
|
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
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
f1120f2d9b121097b7e77709328144af330d0b34
|
|
type in Git (commit, tag, or local/remote branch)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
use it.
|
|
|
|
work needed for branches (at least with git)
|
|
|
|
|
|
|
|
|
|
|
|
|