2015-07-02 13:15:27 +00:00
|
|
|
=====================
|
|
|
|
Contributing to Pungi
|
|
|
|
=====================
|
|
|
|
|
|
|
|
|
2015-11-26 08:47:37 +00:00
|
|
|
Set up development environment
|
|
|
|
==============================
|
|
|
|
|
2017-03-01 09:10:10 +00:00
|
|
|
In order to work on *Pungi*, you should install recent version of *Fedora*.
|
|
|
|
These packages will have to installed:
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
* createrepo
|
|
|
|
* createrepo_c
|
|
|
|
* cvs
|
2017-10-25 08:18:03 +00:00
|
|
|
* gcc
|
2015-11-26 08:47:37 +00:00
|
|
|
* genisoimage
|
|
|
|
* gettext
|
|
|
|
* git
|
|
|
|
* isomd5sum
|
|
|
|
* jigdo
|
|
|
|
* kobo
|
|
|
|
* kobo-rpmlib
|
|
|
|
* koji
|
2017-10-25 08:18:03 +00:00
|
|
|
* libcurl-devel
|
2015-11-26 08:47:37 +00:00
|
|
|
* libselinux-python
|
|
|
|
* lorax
|
2016-08-22 14:08:25 +00:00
|
|
|
* python-jsonschema
|
2015-11-26 08:47:37 +00:00
|
|
|
* python-kickstart
|
2017-10-25 08:18:03 +00:00
|
|
|
* python-libcomps
|
2015-11-26 08:47:37 +00:00
|
|
|
* python-lockfile
|
|
|
|
* python-lxml
|
2017-03-01 09:10:10 +00:00
|
|
|
* python2-multilib
|
2015-11-26 08:47:37 +00:00
|
|
|
* python-productmd
|
|
|
|
* repoview
|
|
|
|
* syslinux
|
|
|
|
* yum
|
|
|
|
* yum-utils
|
|
|
|
|
|
|
|
For running unit tests, these packages are recommended as well:
|
|
|
|
|
|
|
|
* python-mock
|
|
|
|
* python-nose
|
|
|
|
* python-nose-cov
|
|
|
|
|
2016-09-23 08:19:34 +00:00
|
|
|
While being difficult, it is possible to work on *Pungi* using *virtualenv*.
|
2017-10-25 08:18:03 +00:00
|
|
|
Install *python-virtualenvwrapper* (after installation you have to add the command
|
|
|
|
to *source /usr/local/bin/virtualenvwrapper.sh* to your shell startup file,
|
|
|
|
depending on where it was installed by package manager) and use following steps.
|
|
|
|
It will link system libraries into the virtual environment and install all packages
|
|
|
|
preferably from PyPI or from tarball. You will still need to install all of the non-Python
|
2016-09-23 08:19:34 +00:00
|
|
|
packages above as they are used by calling an executable. ::
|
|
|
|
|
|
|
|
$ mkvirtualenv pungienv
|
2017-10-25 08:18:03 +00:00
|
|
|
$ for pkg in createrepo koji libcomps pykickstart rpm rpmUtils selinux urlgrabber yum; do ln -vs "$(deactivate && python -c 'import os, '$pkg'; print os.path.dirname('$pkg'.__file__)')" "$(virtualenvwrapper_get_site_packages_dir)"; done
|
|
|
|
$ for pkg in _deltarpm krbV _selinux deltarpm sqlitecachec _sqlitecache; do ln -vs "$(deactivate && python -c 'import os, '$pkg'; print '$pkg'.__file__')" "$(virtualenvwrapper_get_site_packages_dir)"; done
|
|
|
|
$ pip install -U pip
|
2016-09-23 08:19:34 +00:00
|
|
|
$ PYCURL_SSL_LIBRARY=nss pip install pycurl --no-binary :all:
|
2017-10-25 08:18:03 +00:00
|
|
|
$ pip install jsonschema kobo lockfile lxml mock nose nose-cov productmd pyopenssl python-multilib requests setuptools sphinx
|
2016-09-23 08:19:34 +00:00
|
|
|
|
|
|
|
Now you should be able to run all existing tests.
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
|
2015-07-02 13:15:27 +00:00
|
|
|
Developing
|
|
|
|
==========
|
|
|
|
|
|
|
|
Currently the development workflow for Pungi is on master branch:
|
|
|
|
|
|
|
|
- Make your own fork at https://pagure.io/pungi
|
|
|
|
- Clone your fork locally (replacing $USERNAME with your own)::
|
|
|
|
|
|
|
|
git clone git@pagure.io:forks/$USERNAME/pungi.git
|
|
|
|
|
|
|
|
- cd into your local clone and add the remote upstream for rebasing::
|
|
|
|
|
|
|
|
cd pungi
|
|
|
|
git remote add upstream git@pagure.io:pungi.git
|
|
|
|
|
2015-11-26 08:47:37 +00:00
|
|
|
.. note::
|
|
|
|
This workflow assumes that you never ``git commit`` directly to the master
|
|
|
|
branch of your fork. This will make more sense when we cover rebasing
|
|
|
|
below.
|
2015-07-02 13:15:27 +00:00
|
|
|
|
|
|
|
- create a topic branch based on master::
|
|
|
|
|
|
|
|
git branch my_topic_branch master
|
|
|
|
git checkout my_topic_branch
|
|
|
|
|
|
|
|
|
|
|
|
- Make edits, changes, add new features, etc. and then make sure to pull
|
|
|
|
from upstream master and rebase before submitting a pull request::
|
|
|
|
|
|
|
|
# lets just say you edited setup.py for sake of argument
|
|
|
|
git checkout my_topic_branch
|
|
|
|
|
|
|
|
# make changes to setup.py
|
|
|
|
git add setup.py
|
2015-11-26 08:47:37 +00:00
|
|
|
git commit -s -m "added awesome feature to setup.py"
|
2015-07-02 13:15:27 +00:00
|
|
|
|
|
|
|
# now we rebase
|
|
|
|
git checkout master
|
2015-09-09 07:57:24 +00:00
|
|
|
git pull --rebase upstream master
|
2015-07-02 13:15:27 +00:00
|
|
|
git push origin master
|
|
|
|
git push origin --tags
|
|
|
|
git checkout my_topic_branch
|
|
|
|
git rebase master
|
|
|
|
|
|
|
|
# resolve merge conflicts if any as a result of your development in
|
|
|
|
# your topic branch
|
|
|
|
git push origin my_topic_branch
|
|
|
|
|
2015-11-26 08:47:37 +00:00
|
|
|
.. note::
|
|
|
|
In order to for your commit to be merged, you must sign-off on it. Use
|
|
|
|
``-s`` option when running ``git commit``.
|
|
|
|
|
2015-07-02 13:15:27 +00:00
|
|
|
- Create pull request in the pagure.io web UI
|
|
|
|
|
|
|
|
- For convenience, here is a bash shell function that can be placed in your
|
2015-11-26 08:47:37 +00:00
|
|
|
~/.bashrc and called such as ``pullupstream pungi-4-devel`` that will
|
2015-07-02 13:15:27 +00:00
|
|
|
automate a large portion of the rebase steps from above::
|
|
|
|
|
|
|
|
pullupstream () {
|
|
|
|
if [[ -z "$1" ]]; then
|
|
|
|
printf "Error: must specify a branch name (e.g. - master, devel)\n"
|
|
|
|
else
|
|
|
|
pullup_startbranch=$(git describe --contains --all HEAD)
|
|
|
|
git checkout $1
|
2015-09-09 07:57:24 +00:00
|
|
|
git pull --rebase upstream master
|
2015-07-02 13:15:27 +00:00
|
|
|
git push origin $1
|
|
|
|
git push origin --tags
|
|
|
|
git checkout ${pullup_startbranch}
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
Testing
|
|
|
|
=======
|
|
|
|
|
2016-02-23 12:03:11 +00:00
|
|
|
You must write unit tests for any new code (except for trivial changes). Any
|
|
|
|
code without sufficient test coverage may not be merged.
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
To run all existing tests, suggested method is to use *nosetests*. With
|
|
|
|
additional options, it can generate code coverage. To make sure even tests from
|
|
|
|
executable files are run, don't forget to use the ``--exe`` option. ::
|
|
|
|
|
2016-02-23 12:03:11 +00:00
|
|
|
$ make test
|
|
|
|
$ make test-cover
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
# Running single test file
|
2016-02-23 12:03:11 +00:00
|
|
|
$ python tests/test_arch.py [TestCase...]
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
In the ``tests/`` directory there is a shell script ``test_compose.sh`` that
|
|
|
|
you can use to try and create a miniature compose on dummy data. The actual
|
2016-02-23 12:03:11 +00:00
|
|
|
data will be created by running ``make test-data`` in project root. ::
|
|
|
|
|
|
|
|
$ make test-data
|
2017-10-25 08:18:03 +00:00
|
|
|
$ make test-compose
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
This testing compose does not actually use all phases that are available, and
|
|
|
|
there is no checking that the result is correct. It only tells you whether it
|
|
|
|
crashed or not.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
Even when it finishes successfully, it may print errors about
|
|
|
|
``repoclosure`` on *Server-Gluster.x86_64* in *test* phase. This is not a
|
|
|
|
bug.
|
2015-07-02 13:15:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
Documenting
|
|
|
|
===========
|
|
|
|
|
|
|
|
You must write documentation for any new features and functional changes.
|
|
|
|
Any code without sufficient documentation may not be merged.
|
2015-11-26 08:47:37 +00:00
|
|
|
|
|
|
|
To generate the documentation, run ``make doc`` in project root.
|