Check the configuration of your Jekins charm

Because of different working time zone, sometimes I have to take care of the Jenkins node deployed by Juju, which also maintained by another colleague, to support the colleagues in my time zone. What if I could not access the permission of the Jenkins node?

I take care of the MAAS server to make sure I could provide the hardware resource, e.g. physical nodes, so I could have the permission and credential of the MAAS server and its region controller. The Juju service is provided on the same server, so I could access the Juju profile to deploy the nodes in the lab for sure. The question is, what if I want to access the services deployed by the Juju?

Let's back to the Jenkins service, and take it for example. The answer is simple: check the deployment configuration yaml.

In the README  https://github.com/jenkinsci/jenkins-charm , the default user name is "admin" of the Juju-deployed Jenkins, and it is not recommended (and I think it means "not allowed") to change. Thus the rest of necessary information is to search the deployment configuration yaml hosts the password information, and pray for that the guy to deploy the service did not change its password manually by juju set jenkins password=mypassword.

Build SOLVCON development environment

There are several ways to build its development environment. We could use miniconda directly and only. Or, we could follow the travis.yaml to build the isolated development environment.


Everything comes from miniconda:

export PATH="<YOUR_MINICONDA_ROOT>/bin:$PATH"

Then further configuration to be more automatic. This step is/should be optional:

conda config --set always_yes yes --set changeps1 no
conda update -q conda
conda info -a

Change PS1 option is not necessary. You could decide if you refer it or not.

Create a conda isolated python environment <YOUR_SOLVCON_SRC>/build/env/

<YOUR_SOLVCON_SRC>/contrib/devenv/create.sh

Go to this conda isolated python environment and activate the associated virtualenv

source <YOUR_SOLVCON_SRC>/build/env/start

Please note we won't see the prompt change as what we always get via usual conda activate. Check if we have already been in the conda virtual environment by:

which python

And this python should be the one in the conda virtual environment.

Now it is time to install everything in the conda virtual environment!

<YOUR_SOLVCON_SRC>/contrib/conda.sh

If you want to use the latest pybind11 (optional):

pip install -U https://github.com/pybind/pybind11/archive/master.zip

This month I found an issue and YYC identified it is a real issue of pybind11[1].

Now all packages and libraries are ready to build SOVLCON. Let's build by[2]:

python setup.py build_ext --inplace

That is it! Let's test it a bit:

Unit tests with doctest

nosetests --with-doctest -v

Function tests. Your test machine should be a SSH server to test parallel tests locally.

nosetests ftests/parallel/* -v

In the latest step of travis.yaml, there is a release.sh.

<YOUR_SOLVCON_SRC>/contrib/release.sh

This step is optional if you run SOLVCON locally. The release.sh is for ephemeral build/test nodes. The script strips the build files and packs the necessary libraries with the SOLVCON source to distribute to the test/biuld nodes.

Time to "march" something!! : D

[1] https://github.com/pybind/pybind11/pull/836 No one but me noted the issue for one month!

[2] You may not want to perform "python setup.py install" because this will install your SOLVCON code into the conda environment. We want to keep conda and build/env virtual environment separately.

Summary

In this article we separate the conda and env virtual environment. The advantage to separate them is that we could install common packages via <YOUR_SOLVCON_SRC>/contrib/conda.sh and share them over different build/env virtual environments.