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.
This article covers how to setup CI on the netshow-core project. For details on how to setup Gitlab, review Part 1 of this series
Configure gitlab-ci.yml
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.
Defining gitlab-ci.yml
Below is the .gitlab-ci.yml
for the netshow-core project.
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.
Activating gitlab-ci.yml
-
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 git@gitlab.linuxsimba.test: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.yml
file 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 .gitlab-ci.yml
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
netshow.netshow
module.
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.