Systems - GIT Repository / Development Workflow
This page describes typical workflows using Git CAcerts new version control system of choice.
This is work in progress
Systems - GIT Repository / Development Workflow
- Software Assessors
- Critical Configuration items
Where to get Git
Git is available for all major platforms, you can get it either through the package repositories of your Linux distribution of choice (packages git-core, git-doc and for some helpful GUI tools gitk, git-gui in Debian/Ubuntu) or from the Git website
CAcert on Github https://github.com/CAcertOrg/cacert-devel
Doco on Git for the newcomer:
Before you start using Git for the first time you should do some configuration. Most importantly you need to tell Git your name and email address which shows up in the commit messages:
git config --global user.name "Alice Smith" git config --global user.email firstname.lastname@example.org
Also you probably want to set your favourite editor to edit commit messages and the like (this doesn't have to be the one you want to edit the code with, I personally prefer a non-GUI one for this purpose):
git config --global core.editor nano
Git can produce coloured output e.g. for diffs which can be helpful to keep the overview. You can turn it on by executing
git config --global color.ui auto
If you want to use the Git GUI (I personally use it for staging and commits) then you will notice that the translation is not very helpful so you might want to switch to the English version:
First you have to find out how your $LANG variable is set:
On my system it's de_DE.UTF-8 now you replace the lower case letter pair with en and the upper case one with US, so for my system it's en_US.UTF-8
Now add an alias command to your system by executing (replacing en_US.UTF-8 by the language string fo your system as determined in the previous step)
echo "alias gg='LANG=en_US.UTF-8 git gui'" >> ~/.bashrc
Now you can use the shorthand gg whenever you would normally use git gui to get the English variant
Get the Source Code
Change into the directory where you want the source to be checked out (Git will create a new directory) and execute (replacing <directoryname> with the name of the directory Git should create):
git clone git://git-cacert.it-sls.de/<reponame> <directoryname>
There are several repositories, which hold several versions of the code:
- cacert.git holds the import from the official secure source repository, which represents the code thats currently in production
- cacert-devel.git is a clone of cacert.git, all accepted patches will be imported here, so what you get here is what will be put onto our testing server cacert1.it-sls.de
The choice is yours, grab the official code or review/work on already imported patches.
Make your changes
Once you cloned your working copy, you can start reviewing the code or setup an web server to build your own testing environment. There will be a VMWare image download shortly, which contains an testing environment built by the CACert Production Systems Administrators. Stay tuned.
If you just review the code, please submit a bug message to our mantis bug tracking system located here https://bugs.cacert.org/. If you want to help by adding patches, please make sure you have had a close look into mantis. There are quite some bugs to fix, just in case you need some work *G*. Grab the bug, add your comments.
Once you developed an patch or improvement, you should test your code as far as you can.
As all git repositories are read only (currently, if there is demand, we will think about opening one repo for writing), you need a way to deliver the patch to CACert. There are, as always, more than one possible solutions:
- your git working copy already is a full grown git repository, you can share it by installing git-daemon and just put the "link" to your patch into the mantis bug. A software assessor will then pull the patch from your repository, review the code and merge it into the cacert-devel repository.
- prepare your patch by using the git format-patch command and send it to an software assessor, please ask before you send tons of code, the person owning the mailbox might be busy and unable to process your patch in an appropriate time!
- make diff files and attach the diffs to the mantis bug
In either case, once the code is in the cacert-devel repository, CACert will start official testing runs on cacert1.it-sls.de. Usually several issues will be bundled and tested within one cycle. After the patches have been signed off, code will be forwarded to the Release Manager who will promote the code to the production system.
Please note that this is WiP, if you think you need more means to submit patches, please stand up and speak. Same for all other aspects of the process.
Commands to make the patch, to add a new file and to adjust from an old one
- "git format-patch" produces a email-style file for each commit you have done.
"git show <commit>" shows information about a commit (e.g. commit message and changes) in a more general style
- you can also get patches only by using "git diff".
Fetch & Merge current official tarball to cacert-devel
Right now the process is under development, thus parts of the old procedures are still in use. This includes the generation and publication of a new tarball containing the whole source code, once a change to the webdb code was put live. We need to get this code and merge it to the devel repository to be sure that all changes which are made NOT through the new process using git nevertheless make it into our git development repository. Here is how it works:
git clone ssh://git-cacert.it-sls.de/var/cache/git/cacert.git cacert
git clone ssh://git-cacert.it-sls.de/var/cache/git/cacert-devel.git cacert-devel
- get tarball and extract into cacert working copy
- cd cacert
- rm -r ./*
tar -xj --strip=1 -f <nameoftarball>
- git status
- restore eventually deleted .gitignore files (marked as deleted): i.e. git checkout includes/.gitignore
git add <new files> # add new files
- git commit -a # automatically handles modifies and deletes, but NOT new files
- git push
- merge changes with cacert-devel, can be done the easy or (little) hard way
- git remote add cacertlive git://git-cacert.it-sls.de/cacert.git
- easy way: git pull cacertlive master # this is the easy way, just merge automatically, no manual intervention
- hard(er) way: use git fetch, git checkout/diff and git merge to examine diffs
- git log origin/master..master # see local commits vs. origin repository
git diff <ref>..<ref> # display file by file diffs between refs # you can examine changes even when using pull
- git push
How to reset the testserver to a defined state ?
- Well all that is needed is to check out the right version (0a24e915fdcbf745141e4534b64fdef57319d250) on the test server
- $ cd /path/where/the/checked/out/copy/lies
- $ git checkout 0a24e915fdcbf745141e4534b64fdef57319d250
How to update your local copy to the lastest revision from central repository ?
cd <your local directoryname> git pull
git clone git://git-cacert.it-sls.de/<reponame> <your local directoryname>
proposed local path
mirror of current live webdb state, should be the same tarball as under download link https://www.cacert.org/src-lic.php
current development branch
Testserver Mgmt System repository current state
Birdshack repo (was on .cl)
moved Boardvoting repo from .cl
RoundCube CRT Auth
Getting commit access
Contact Markus with NAME (your unix/ssh style username) and SSH public key. Once installed, try this:
$ git clone ssh://NAME@git-cacert.it-sls.de/var/cache/git/REPONAME.git LOCAL_REPO_DIR
(change the CAPS parts) This brings you your own personal repository, cloned form the master. To send your committed changes up to the master, do
$ git push
- GIT port: 9418
This is the new GIT repository for Software-Assessment and Developers
This system is an etch ? lenny ? vm on vmware-host.it-sls.de (ESX)
- IP Internet: 188.8.131.52 git-cacert.it-sls.de
- IP Local : 10.38.6.92 git-cacert.it-sls.de
This is it
- Wytze van der Raay
- Markus Warg
- Andreas Bäß
SSH access for remote administration
Outbound network connections
Non-distribution packages and modifications
Risk assessments on critical packages
Critical Configuration items