Binary Distribution

Jenkins Setup

Jenkins server runs on Linux, Jenkins agents on Linux, Mac and Windows. The server instance manages Jenkins, the agents run the jobs.

On Linux, to start Jenkins, run command:

docker stop jenkins-master

docker rm jenkins-master

docker run -d -u root --name jenkins-master -p 8080:8080 -p 50000:50000 --restart unless-stopped -v /home/eman2/jenkins_home:/var/jenkins_home -e PLUGINS_FORCE_UPGRADE=true -e TRY_UPGRADE_IF_NO_MARKER=true --restart unless-stopped jenkins/jenkins:lts

Agents need to have Java installed and passwordless ssh connections from the Linux server set up.

Jenkins Setup on Linux

Credentials

PATH

Jenkins Setup

  1. Jenkins master needs PATH prepended with $CONDA_PREFIX/bin

Jenkins Setup

  1. Login info: 10.10.11.176:8080/ username: eman2
  2. Jobs
  3. Settings, Plugins ?
  4. Nodes http://10.10.11.176:8080/computer/

  5. Binary builds require conda-build, constructor

Packaging is done with constructor, a tool for making installers from conda packages.

  1. JenkinsCI: Jenkinsfile

    1. Secrets like ssh keys are stored locally in Jenkins
    2. Some env vars need to be set by agents:
      1. HOME_DIR, DEPLOY_PATH, PATH+EXTRA (to add miniconda to PATH).
      2. PATH+EXTRA is not set on win. (?)
        1. Now, it is set on win, too.
    3.  Launch method: via SSH
         Advanced:
           Prefix Start Agent Command: "D: && "
    4. On windows for sh calls in jenkins to work "Git for Windows" might need to be installed.
  1. Binary builds on local build machines.
    1. Manually triggered by including "[ci build]" anywhere in the last commit message. Manually triggered builds on master branch are uploaded as continuous builds and builds triggered from any other branch are uploaded to testing area.

    2. Any branch in the form of "release-" triggers continuous builds without having to include "[ci build]" in the commit message. Once the release branch is ready, release binaries are manually copied from cont. builds folder into the release folder on the server.

Linux

docker run -d -u root --name jenkins-master -p 8080:8080 -p 50000:50000 --restart unless-stopped -v /home/eman2/jenkins_home:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock -e PLUGINS_FORCE_UPGRADE=true -e TRY_UPGRADE_IF_NO_MARKER=true --restart unless-stopped cryoem/jenkins:dev

Mac

slave clock sync https://blog.shameerc.com/2017/03/quick-tip-fixing-time-drift-issue-on-docker-for-mac docker run --rm --privileged alpine hwclock -s

Windows

OPENGL: https://github.com/conda/conda-recipes/blob/master/qt5/notes.md

Anaconda

Dependencies not available on anaconda or conda-forge are available cryoem. The binaries are built and uploaded using conda-forge's conda-smithy. conda-smithy takes care of generating feedstocks, registering them on GitHub and online CI services and building conda recipes.

EMAN2 is built with conda-build using binaries from https://anaconda.org, packaged into an installer with constructor as of v2.2.

  1. conda is the package manager.

  2. https://anaconda.org is the online repository of binaries.

  3. conda-build is the tool to build from source.

  4. constructor is the tool to package eman2 and dependency binaries into a single installer file.

EMAN2 is distributed as a single installer which includes all its dependencies.

Conda

Packages that are available on https://anaconda.org can be installed into any conda environment by issuing the command conda install <package>. Conda installs the package along with its dependencies. In order for packages to benefit from this automation, they need to be packaged in a specific way. That can be done with conda-build. conda-build builds packages according to instructions provided in a recipe. A recipe consists of a file with package metadata, meta.yaml, and any other necessary resources like build scripts, (build.sh, bld.bat), patches and so on.

Recipes, Feedstocks and anaconda.org channel: cryoem

Most of EMAN2 dependencies can be found on anaconda's channels, defaults and conda-forge. A few that do not exist or need to be customized have been built and uploaded to channel cryoem. The recipes are hosted in separate repositories on GitHub. Every recipe repository follows the feedstock approach of conda-forge. See here for a complete list.

Feedstocks

General instructions

  1. Existing feedstocks
  2. Files to edit: recipe/, conda-build.yaml, conda-forge.yaml
  3. conda create -n smithy conda-smithy -c conda-forge
  4. conda-smithy rerender
  5. More info in conda-smithy/README.md, conda smithy -h, conda-forge.org/docs
  6. New feedstocks
  7. conda-smithy/README.md, conda smithy -h

Conda-smithy Workflow

Conda smithy uses tokens to authenticate with GitHub.

Conda-smithy commands:

Build System Notes

CMake

  1. libpython can be linked statically or dynamically when python is built. It is important for python extensions to be aware of the type of linking in order to avoid segfaults. This can be accomplished by querying Py_ENABLE_SHARED.

       1 python -c "import sysconfig; print(sysconfig.get_config_var('Py_ENABLE_SHARED'))"
    

    In EMAN, it is done in cmake/FindPython.cmake

  2. OpenGL detection when Anaconda's compilers are used is done using a cmake toolchain file.

  3. glext.h file needed for OpenGL related module compilation is already present on Linux and Mac. On Windows, it is manually copied once into C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\gl. On Appveyor it is downloaded as part of env setup every time a test is run.

Jenkins Docker

  1. docker-compose.yml at home dir in build machines
  2. TZ: https://stackoverflow.com/a/46384925

  3. Agent nodes setup
  4. Server and agent per machine vs single server and os agents

Docker

Docker images and helper scripts are at https://github.com/cryoem/docker-images https://github.com/cryoem/build-scripts.

Command to run docker with GUI support, CentOS7:

xhost + local:root

docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY cryoem/eman-nvidia-cuda8-centos7

# When done with eman
xhost - local:root

:FIXME: Runs as root on Linux. chown doesn't work, the resulting installer has root ownership.