Main Page: Difference between revisions

From Wikitech
Content deleted Content added
Ryan Lane (talk | contribs)
Ryan Lane (talk | contribs)
Line 148: Line 148:
git diff production origin/production | less
git diff production origin/production | less
git merge
git merge

=== Books, guides, tutorials, documentation, etc. ===

* [http://book.git-scm.com/index.html Community git book]
* [http://gerrit.googlecode.com/svn/documentation/2.2.1/index.html Gerrit documentation]

Revision as of 20:55, 9 September 2011

Access rights

Anonymous users

You'll need to have an account created for you. If you currently have SVN access, then you have an account, but need to have it linked to Labs. We are still working out the account activation process, but hope to have it done soon.

Logged in users

After creating an account, you can:

Once you add a key, you'll be able to log into an instance in the main project testlabs. It may take up to 30 minutes for your key to be propagated to all instances.

If you'd like to create instances, you'll need to have an admin add you to a project, and to the sysadmin role in that project.

You can make queries for nova resources; currently Nova instances have semantic properties enabled.

After logging in, you can also access Gerrit; if you wish to do git checkouts of the puppet repositories, you'll need to log into Gerrit, and add your SSH key there as well. Note: it would be nice if Gerrit could use LDAP for its SSH keystore, instead of its database; I've opened a bug for this, if you'd like to help, please add that feature to Gerrit!

Admins

Wiki Admin

If you are a wiki admin, you can:

Net Admins

If you are a NetAdmin, you can:

Sys Admins

If you are a sysadmin, you can:

After creating an instance, you'll get an email notifying you that it is ready to be logged into. If you did not add an SSH key prior to creating the instance, you'll need to wait until your key is propagated to the instances (which can take an additional 30 minutes).

Cloud Admins

In addition to all actions that sysadmins and netadmins, you can:

Access FAQ

  • Q: I was added to a group that gives me access to something in git, but it isn't working, what's wrong?
    • A: Once you have been added to the group, you need to log out of gerrit, then back in. Gerrit pulls its groups from LDAP, but caches them. Logging out, then back in re-synchronizes your groups, and thus clears the cache.

Git/Gerrit and the puppet repositories

Note: Access is currently limited to staff developers and operations engineers. This will change soon.

Checking out the puppet repositories

We have the following main repositories and branches:

  • operations/puppet
    • production (HEAD)
      • used in production
    • test
      • used in the testlabs project
  • operations/private
    • master (HEAD)
      • only used in testlabs project

To check out the production branch of the puppet repo, you can clone it like so:

git clone ssh://<username>@gerrit.wikimedia.org:29418/operations/private.git

To check out the test branch of the puppet repo, you can clone it like so:

git clone ssh://laner@gerrit.wikimedia.org:29418/operations/private.git -b test

Updating your local repository

After you do the initial repository clone, git will automatically set up a remote tracking branch for you. You simply need to fetch/merge or pull:

git fetch
get diff <branch> origin/<branch>
git merge

or:

git pull

Making changes

After cloning the repo, you can make changes the normal git way:

<make changes>
git add <newfiles>
git commit -a

After doing so, you'll need to push the changes for review; for instance, here's how to push to the test branch of the puppet repository:

git push ssh://<username>@gerrit.wikimedia.org:29418/operations/puppet HEAD:refs/for/test

You can shorten that by adding a remote:

git remote add puppet ssh://<username>@gerrit.wikimedia.org:29418/operations/puppet

Now you can push for review like so:

git push puppet HEAD:refs/for/test

You can shorten this further by making an alias:

git config alias.push-for-review-test "push puppet HEAD:refs/for/test"

Now you can push for review like so:

git push-for-review-test

Here's the alias for production:

git config alias.push-for-review-production "push puppet HEAD:refs/for/production"

Also, staff operations members have the ability to skip the review step; to do so, simply do a push:

git push puppet

Here's the remotes and aliases for the private repo:

git remote add private ssh://<username>@gerrit.wikimedia.org:29418/operations private
git config alias.push-for-review-private "push puppet HEAD:refs/for/master"

Making the changes live in puppet

Test

Changes merged in the test branch will immediately go live in puppet.

Production

Changes for production need to be pulled manually; this is done for security purposes. Here's the procedure you should use:

cd ~/productionrepo/puppet
git fetch <changeid-you-just-reviewed-or-committed>
git diff production origin/production | less
git merge

Books, guides, tutorials, documentation, etc.