When the supplied git revision is not a tag or remote branch checkout
the revision locally.
Change-Id: I42bdd4e089036d7520d63067862b0be7245c998f
Reviewed-on: https://review.openstack.org/17568
Reviewed-by: James E. Blair <corvus@inaugust.com>
Reviewed-by: Paul Belanger <paul.belanger@polybeacon.com>
Approved: Clark Boylan <clark.boylan@gmail.com>
Reviewed-by: Clark Boylan <clark.boylan@gmail.com>
Tested-by: Jenkins
Previously the tag checkout code would checkout a new branch for the tag
using the current branch (master) as the base for the new branch.
Instead use the actual tag as the base for the tag branch.
Change-Id: Ic18bad7d19da3298b73f3e4185ca0bb5d4b3bf04
Reviewed-on: https://review.openstack.org/16030
Reviewed-by: Paul Belanger <paul.belanger@polybeacon.com>
Reviewed-by: James E. Blair <corvus@inaugust.com>
Approved: Jeremy Stanley <fungi@yuggoth.org>
Reviewed-by: Jeremy Stanley <fungi@yuggoth.org>
Tested-by: Jenkins
ensure => latest should work and trigger when the remote has new
revs, and not at other times. It will handle tags and branches apparently
and will also handle not specifying a branch in the revision.
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.
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.
These are called when the type is retrieve'd. Without this, the ownerships
for any .git metafiles fetch'd durring the retrieve will be owned by
root. This patch fixes that by invoking update_owner_and_excludes after
fetch'ng
This will work around the issue in http://projects.puppetlabs.com/issues/6907, as the agent run will no longer fail if one of the commands is not installed.
This gives you enough time to install the necessary packages through Puppet (make sure you get the dependencies right), as the agent won't fail unless you really start accessing the repository.
If vcsrepo is used with ensure => latest to keep something from a larger repository checked out it will trigger an update every time something changes anywhere in the repository, not just in the part that’s actually checked out.
In combination with a busy development team and a vcsrepo resource with notify => Service[foo] this means frequent restarts of a service for no good reason.
The attached patch solves the issue by looking at the “Last Changed Rev” line from svn info instead of “Revision”.
Patch thanks to: Knut Arne Bjørndal
The basic_auth feature allows the manifest to specify an optional
basic_auth_username and basic_auth_password to be sent to the subversion
server over HTTP(S).
Adding --non-interactive to all svn commands just lets svn know that
there's not a user on the other end to send y/n questions.
Fixes a number of issues with the git provider. remote_branch_revision?
method was always returning true because it would always at least return
something, even if that something was a zero length array. You normally
don't desire a tag to become a branch since it creates ambiguity so I
removed that. latest method had no concept of (no branch) and so would
fail if you switched to a remote branch or a tag. Then finally
revision sha1 returned by 'git rev-parse' for tags is not the revision
of the commit the tag represents. We have to use 'git show' and do
some text parsing to actually figure out which commit goes with which
tag.
* support recursive chown on repo
* support checking out tags (git)
* support adding excludes/ignored files
* dropped a few unused methods
* rework git provider logic a bit
svn provider now gets the latest revision from the repo, rather than the checkout
Test with revision => <some value> as well
now when ensure => latest, only refresh dependent resources if the
repo is actually updated
Tidied up debug messages
Clark Boylan