Biking Endorphines - Where to Begin?

What Github offers us.

Since project Biking Endorphines will be maintained at open-source Github, let's check what type of tools does Github offers us.

To narrow down our research, let's just find tools available as "free" - they will all be an Continuous Integration tools which purpose will be to build && test.

1. Jenkins CI

This is a fork of Hudson (or a Hudson is fork of Jenkins) - how-ever the split for Hudson/Jenkins was, Jenkins has more maintainers and commits which means it is more-actively maintained.

Jenkins is suppported natively by github with it's available services-integration-to-project

Advantage:

  • You can tweak the whole build & test process within it's internals.

  • Support for all languages (if you can set-it-up)

Disadvantage:

  • Setup process takes a while.

  • Need to configure most of the setup with web-ui

  • Unfortunatelly It's not something new for me.

2. SonarQube

Link: SonarQube Integration for Github

Summary: Open Source Platform for code inspection and code quality.

This uses pull-requests and before you have code available at "master" branch, you will have to merge it with this SonarQube tool. It will automatically get pull-request and using linguistics check code quality. You may also review code and find bugs on your own.

About pull-requests

How to create your first pull-request with Github

Advantage:

  • More complex setup for code-quality.

  • Support for multilple languages

Disadvantage:

  • A little bit to complicated and needs more time to spend for setup than I have previously.

  • Only for setting up code-quality tests

I may go back to this solution in future.

3. Travis CI.

About this CI I've heard for more then 2 years from now. I've always wanted to investigate usage of this CI tool.

Advantage:

  • It's maintainance focuses only on one .travis.yml file that has all scripts for running scripts in it.

  • What ever you code in your scripts, travis will take it.

Disadvantage:

  • It's only hosted online, if you want to deploy it on your local server/machine (correct me if I'm wrong) - if it's only for your investigation than in my opinion you could use it.

  • Not free for private projects/commercial projects not visible for public - Check Prices for Commercial Usage

So for me, dispite disadvantage's - is the choice - at least for now.

Issue -bug-enhancement Tracking software integrations

1. Issue tracking software available I've seen at project service integration setup.

  • Redmine
  • Trac
  • Jira.

2. Issue tracking I'll be using.

In my commercial experience I've used all of this bug-tracking software, hence it's a learning process I'd like to skip this to Github possibilities that are for me still a new-thing.

Add to this, that some of this tracking software can be setup as a private servers, and this project is a open-sourced - this collapse - hence Github Issues and Projects tabs are going to be used by me in this project.

Travis - be prepared - here we go!

To start with travis configuration:

1. Create .travis.yml file with appropriate configuration for your project

language: python
python:
    - "2.7"
install: "pip install -r requirements.txt"

script: 
    - make pylint

And the Makefile:

requirements:
    pip install -r requirements.txt
pylint: requirements
    pylint bikingendorphines --rcfile=.pylintrc

Make task called pylint will be executed only when requirements task will finish properly without error - that may be unneeded since .travis has already the same command at his install task, but I wanted to make sure it will work no-matter what.

As you've noticed only one script is integrated for now - it's a simple pylint check.

To setup pylint with configuration file .pylintrc

pip install pylint

pylint --generate-rc-file > .pylintrc ## this will generate a standard pylintrc configuration file!

You may need to tweak your .pylintrc file for better code-quality-check

2. Add project using TravisCI Profile Site

You need to login to your account of github.com using TravisCI Profile site and then select project that you want to have automatical builds.

3. Push this file to your repository

After setting up at TravisCI site project that will use auto-builds, you can now push your first .travis.yml file to your github repository.

4. See what happens at Travis-CI status page of project.

I've prepared for the worst-case scenario and that's why I've used only pylint for now to just check how the process of integration with Travis works - still had to overcome some issues with pylint for it not to break at any-point.

You can check yourself how the process of pylint'ing at TravisCI works for my project here:

Build Status

LL (Lessons Learned)

1. I have a poor time-management.

Solution:

2. Configuration of Integration tools are not an easy-peasy-lemon-squeezy

It does not matter if it's a SonarQube / Trac/ TravisCI / Jenkins - all of this integration tools will take time to configure.

Issues:

  • Since I'm starting this project, besides of TravisCI .travis.yml I had to:

    • virtualenv for pip requirements.txt file using pip freeze > requirements.txt

    • install pylint using pip pip install pylint

    • install framework I'll be using for for purpose of pylint check pip install Django

    • create initial django-project django-admin startproject bikingendorphines for pylint to be able to work on files.

    • Go to TravisCI Profile Site and FIRST enable TravisCI builds on github project you wish to have auto-builds. Then push .travis.yml file to repository to trigger automatical build.

Solution:

  • Estimate more time for integration tools !

3. Django initial project setup is not perfect for default values of pylint-checker configuration

Solution:

  • For each of new "directories" add __init__.py - so that all directories becomes "python modules"

  • Needed to use #pylint: disable= for:

    • Default django configuration variables that are not compatible with "invalid-name" check (they are seen as constants by pylint checker - and as a constants, should be upper-case, but they are not - if you are aware why, let me know in comments below )

      • urlpatters at urls.py
      • application at wsgi.py

    • Warning of importing django and not using it at source-code at manage.py in line with import django

  • Pylint has a checker for locally disabling line checks at code-level. Since I've used "#pylint: disable" - pylint found this lines and throw at me with error of locally-disabled - To by-pass this error - I've added locally-disabled to disable at .pylintrc

Acknowledgements

What's next

  • Integration of git-commits with Issues at Github

  • Features I'll focus in this project.

  • Tools section showing what tools I've used for purpose of each blog-post-session.

Comments

comments powered by Disqus