Proposition for Instant-CI
What is Instant-CI?
"
Keeping in line with what a CI is Instant-CI aims to do the same, being a handy developer tool which increases efficiency in terms of time and ease of access, but the same being available locally.
It will run on a container which will be running in the background on the users system, the container will pick up on changes done by the user ( via commits or manual triggers) and will have the capability to build install and run PTL tests on the pbs of the users repository, for all this the user may not worry about underlying dependencies or any caveats. It will also support a build and test history and a web interface.
Problems as of now (or things that restrict us ):
→ We need to use a Virtual Machines for windows or mac, to build and test on all platforms for pbs.
→ Dependencies must be installed on all these systems, and maintained as well to take care of smooth build and install for pbs. These dependencies are not the same, for each flavour of unix/linux is another problem.
→ To run test cases one must install PTL with the same version of installed PBS.
Use cases for Instant-CI (or why it's advantageous):
→ Eliminates the need for use of Virtual Machines, as the container image of any platform can be pulled and used as for build and test.
→ Eliminates the need for installation of PTL as all the source for running PTL can be run inside a container along with pbs.
→ Makes use of travis to create a travis like environment even before one raises a pull request.
→ Multiple instances of pbs can be running simultaneously as each will be running in a separate container ( which is much more lightweight than running multiple installs on a VM or multipe VMs.), with their own version of PTL running.
→ Automating the entire build, install and test workflow to save time and increase efficiency.
Current workflow vs Proposed workflow:
CLI for Instant-CI:
Instant-CI will use travis for it's build. Which after initial setup just has the option to just "build" pbs. It uses source installation both for PTL and PBS and will have the option to generate rpms.To keep the current workflow as similar as it can be to the CI's workflow, here are the list of commands that I am proposing to run on Instant-CI. This will also keep in view that inclusive of automation Instant-CI also offers modularity to the developers. They will also have access to logs with a build history supported by Instant-CI which will be inside the installed folder:
ci: This will be a wrapper for all ci commands like make, make install, or test. This wrapper will display the stdout on the host terminal. Pressing "Ctrl + C" will terminate the ongoing command and leave the user inside the container terminal. At this point the user will be able to attach "gdb" or "valgrind" which will be pre-installed in the container.
ci --start: This script should be shipped in the repository along with source for Instant-CI. By default the CI script can be called in the cloned directory, will take option for user specified directory. It will also take as arguments (in future versions) the to setup a CI with multi-node container setup, thus having the details the details for specific pbs requirements as no of servers, moms etc. It will also accept as an argument wether or not web-interface needs to be installed. This will also have an option to set up a container of a different os, ex centos,ubuntu or opensuse. which will default to centos7.
eg. Simply go to the ci folder and run the following.
./ci --start #The above command will run ci with centos:7 as it's base container. ./ci --start="ubuntu" #This will run ci with container as "ubuntu", all docker hub images are compatible with ci. ./ci --start="opensuse/leap:15" --build #The above command will force the container to rebuild all dependencies.
ci --configure: user can provide pbs configure options.
./ci --configure #The above command will run the pbs configure with default options "--prefix=/opt/pbs --enable-ptl" . #Note that if you have already specified the configure options and are running it again then simply calling --configure will run the last called options ./ci --configure='CFLAGS="-g -O2 -Wall -Werror" --prefix=/tmp/pbs --enable-ptl' #The above command is an example of how to call a custom configure command.
ci --make: A command that will simply build PBS and PTL source code and not install.
./ci --make #this will invoke make -j8 for pbs
ci --install: For this to run the source must be compiled, it will throw an error if this is not the case.
./ci --install #this will invoke make install for pbs
ci --test: By default it should run "–smoke" tag for PTL, else the user can specify what pbs_benchpress options they need.
./ci --test #With no options specified this will run "--tags=smoke" for ptl, however if you have already ran this command before it will run the last specified options ./ci --test="-f pbs_smoketest.py" ./ci --test="--tags=smoke" #the above method are examples how to call a custom test case, keep in mind that benchpress is called from the installed 'tests' dir of PTL
ci --run: This command will manually trigger the build for automatic testing of build install and test.
./ci --run #This command will invoke configure(with default options) ,make, install and test. With no options specified this will run "--tags=smoke" for ptl, however if you have already ran this command before it will run the last specified options ./ci --run="-f pbs_smoketest.py" ./ci --run="--tags=smoke" #the above method are examples how to call a custom test case, keep in mind that benchpress is called from the installed 'tests' dir of PTL
ci --delete: which will stop any ongoing build in the container for the moment and remove it build.
./ci --delete #If you want to get rid of the container simply invoke this command.
Un-installation should be just removing the directory which is no longer required as it will get rid of the entire developer environment.
A overview of the instant-CI design:
Source: While installing instant-CI we will refactor travis into the easy-install command such that it uses the already present travis install scripts and gives us different container platforms to work with like ubuntu, opensuse or centos. The default will be centos:7.
Install target: ".ci" directory will have the necessary files after installation, making sure it also goes into the git-ignore. It will be installed inside the pbs source directory itself unless specified otherwise. and will contain logs with respect to different builds done by the CI.
CLI: The ci commands will be in .ci folder. Since they are essentially doing a build install and test in travis, we want travis to use ci commands and be tightly coupled with it
Containers: There will be two containers running in the background. One will be the specified platform, which will run the pbs buld, install and test and the other will contain the http server which will run the web-ui for the ci.