Continuous integration (CI) is the hot new thing in the computer infrastructure world. To learn CI I'm going to practise it using one of my favorite python projects - netshow.
Gitlab provides builtin CI support. Much like Github supports Travis CI by default. To activate CI support, create a
.gitlab-ci.yml file in the root of the Git repo.
Below is the
.gitlab-ci.yml for the netshow-core project.
test:3.5: image: python:3.4.5-wheezy script: - netshow-lib/test.sh - netshow/test.sh
It says it will run 2 jobs. The first is using a python 2.7 container, and the second will use a python 3.4 container. This is done to ensure that the code is compatible with both established python versions and the upcoming python release set to take over.
Add SSH Key so passwordless access to the Git repository is possible
If you are using MacOS or Linux modify the $HOME/.ssh/config to include the gitlab SSH connection info
Host gitlab.linuxsimba.test Hostname localhost Port 9022 User git
- git clone netshow-core from the local gitlab server
% git clone firstname.lastname@example.org:demo/netshow-core Cloning into 'netshow-core'... remote: Counting objects: 1227, done. remote: Compressing objects: 100% (459/459), done. remote: Total 1227 (delta 712), reused 1227 (delta 712) Receiving objects: 100% (1227/1227), 239.22 KiB | 0 bytes/s, done. Resolving deltas: 100% (712/712), done. Checking connectivity... done.
- Create a branch add the
.gitlab-ci.ymlfile along with other necessary changes to make Gitlab CI work
wget https://goo.gl/0jfMmJ -o $HOME/add_ci.diff git checkout -b add_ci_stuff patch -p0 < $HOME/add_ci.diff git add . git commit -m "add CI" git push origin add_ci_stuff
Create a Pull Request
Then in the Gitlab UI, create a Pull request and watch the Gitlab runner execute
the tests defined in
Observe the Status of the tests
One of the tests failed. The build of netshow-core using python-3.5. Details can be seen by clicking on the failed test. Gitlab will move to the pipeline section showing the docker container output of the failed build.
Iterate on the Pull Request. Fix the failed build
Here is the beauty of CI. When a test fails, all that needs to be done is to fix the code in the
add_gitlab_ci branch. Commit this code and the tests will automatically run again. The fix was to disable pylint tests on the
diff --git a/netshow/tox.ini b/netshow/tox.ini index a9f6123..ab3f374 100644 --- a/netshow/tox.ini +++ b/netshow/tox.ini @@ -13,4 +13,3 @@ commands= python setup.py bdist_wheel pip install --find-links=./dist netshow-core nosetests --first-package-wins - pylint -E netshow
The build passed. Gitlab was set with desktop notifications so a desktop alert was issue when the build finished.
Rebase the request, before the request is committed
Rebasing means taking all the patches in the Pull request and reducing it down on just one gigantic patch.
git rebase -i origin/master
An editor will open. Keep the
pick setting for only the first commit. Change all other commit settings to
squash and save. The commits will be squashed down to 1 commit. Then force the new single commit to overwrite the branch
git push origin add_gitlab_ci -f
Submit the Pull Request
The next part of the series is work with multiple branches and how CI can be used to ensure the stability of the application. Specifically how to commit to a develop branch simulating a dev release. Then at some point, merging the dev release changes back to master to simulate creating a new production release.