Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In order to make sure that the home directory for the test user is
created and destroyed, add managehome to the setup and teardown
manifests for the testuser.
|
|
In order to ensure that the git daemon is running for the proper test, the setup
and teardown calls for git daemon hav been moved into the context block for
testing the git protocol.
|
|
|
|
|
|
The git_clone_protocols_spec.rb will be used to enumerate over the
available protocols for git to use to clone to disk. The initial
skeleton includes the 'file://' protocol test as well as support
key files to be used later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|