Files
fm-orchestrator/docs/CONTRIBUTING.rst
2016-11-16 16:16:43 -05:00

110 lines
4.0 KiB
ReStructuredText

Development
===========
We have two mechanisms for quickly setting up a development environment. `docker-compose` and `vagrant`.
In order to to setup a development environment, it is required that you have
your Fedora kerberos credentials generated in a *special location*. Before
starting your development environment, run the following::
$ KRB5CCNAME=FILE:/var/tmp/krbcc kinit YOUR_USERNAME@STG.FEDORAPROJECT.ORG
If you have problems in later steps with kerberos reading those credentials
inside the `scheduler` container, you should check that `/var/tmp/krbcc` exists
on your machine and that *it is not a directory*. Try removing it with `$ sudo
rm -rf /var/tmp/krbcc` and running `kinit` again.
Docker
------
You can use docker containers for development. Here's a guide on how to setup
`docker <https://developer.fedoraproject.org/tools/docker/about.html>`_ and
`docker-compose <https://developer.fedoraproject.org/tools/docker/compose.html>`_
for Fedora users (it's just a `dnf install` away). Mac users should see `these
docs <https://docs.docker.com/docker-for-mac/>`_.
After your docker engine is set up and running and docker-compose is installed,
you can start the entire development environment with a single command::
$ docker-compose up
That will start a number of services in containers, including the `frontend`
and the backend `scheduler`. You can submit a local test build with the
`submit-build.sh` script, which should submit an HTTP POST to the frontend,
requesting a build.
You may want to wipe your local development database from time to time. Try the
following commands, and you should have a fresh environment::
$ rm module_build_service.db
$ docker-compose down -v && docker-compose up
If things get really screwy and your containers won't start properly, the best thing
to do is to rebuild the environment from scratch::
$ docker-compose down -v
$ docker-compose build --no-cache --pull
The first command will stop and remove all your containers and volumes and the second
command will pull the latest base image and perform a clean build without using the cache.
Vagrant
-------
Once your environment is setup, run (depending on your OS, you may need to run it with sudo)::
$ vagrant up
This will start module_build_service's frontend (API) and scheduler. To access the frontend, visit the following URL::
https://127.0.0.1:5000/module-build-service/1/module-builds/
At any point you may enter the guest VM with::
$ vagrant ssh
To start the frontend manually, run the following inside the guest::
$ cd /opt/module_build_service/src
$ python manage.py runssl --debug
To start the scheduler manually, run the following inside the guest::
$ cd /opt/module_build_service/src
$ python module_build_service_daemon.py
Alternatively, you can restart the Vagrant guest, which inherently starts/restarts the frontend and the scheduler with::
$ vagrant reload
Logging
------
If you're running module_build_service from scm, then the DevConfiguration from
`config.py` which contains `LOG_LEVEL=debug` should get applied. See more about
it in `module_build_service/__init__.py`, `config.from_object()`.
fedmsg Signing for Development
------------------------------
In order to enable fedmsg signing in development, you will need to follow a series of steps.
Note that this will conflict with signed messages from a different CA that are on the message bus, so this may cause unexpected results.
Generate the CA, the certificate to be used by fedmsg, and the CRL with::
$ python manage.py gendevfedmsgcert
Setup Apache to host the CRL::
$ dnf install httpd && systemctl enable httpd && systemctl start httpd
$ mkdir -p /var/www/html/crl
$ ln -s /opt/module_build_service/pki/ca.crl /var/www/html/crl/ca.crl
$ ln -s /opt/module_build_service/pki/ca.crt /var/www/html/crl/ca.crt
Create a directory to house the fedmsg cache::
$ mkdir -p /etc/pki/fedmsg
Then uncomment the fedmsg signing configuration in fedmsg.d/module_build_service.py.