Page tree
Skip to end of metadata
Go to start of metadata

 

Accounts used

Jenkins build jobs are linked to user accounts which are defined in:

Jenkins  > Credentials > Global credentials

These accounts will usually have the necessary permissions on the repository being accessed.

It should be noted that in the Jenkins home directory, there are two pairs of public keys.   The first - used by default (id_rsa) and also held by ansible is generally read-only in nature since Jenkins will usually just pull the files it requires to run a build.     However, in the cases where read/write access is required, id_rsa2 can be used.  An example of how this is done is shown for the SRS below.

Tweaks for specific Projects

SRS - International Release Daily Build via SNOMED Release Service (snomed-release-service-daily-build)

The public key for jenkins' id_rsa has been used in GitLab (git.ihtsdotools.org) as a "deploy key".   This is, by definition, read only.    Because of this restriction, a 2nd key has also been made available for when read/write operations are required.  The Jenkins user defined in GitLab uses a 2nd public key, and this relates to the 2nd set of keys on the jenkins server / jenkins user (jenkins.ihtsdotools.org), id_rsa2 / id_rsa2.pub.    

To allow a process running on the Jenkins server to access this account when connecting to GitLab, an override of the default rsa key has been defined in file /var/lib/jenkins/.ssh/config:

.ssh/config
Host git.ihtsdotools.org
IdentityFile ~/.ssh/id_rsa2

SRS Triggering

The triggering for the international release build is quite convoluted, but it does mean that the process can run in a robust manner without failing when the required dependencies are not found.   It works like this:

  1.  A monitoring project is run every 10 minutes ( Monitor published WBRP International Release Daily Build - git.ihtsdotools.org:ihtsdo/workbench-daily-build-sync.git )  this project is bound to the Global Credential for Jenkins which relates to the 1st id_rsa key pair ie read only.
  2. If new Workbench files are detected, the code that runs in this process modifies latest-daily-export.txt and checks that in using git.   Now because of the override (in .ssh/config) mentioned above, this subsequent update process uses the 2nd jenkins account to allow write access to the repository.
  3. A completely separate Jenkins project (Project Trigger SRS International Release Daily Build when WBRP published) watches the same repository for updates (which will happen when new workbench content is detected) and basically builds nothing, but as a post-build action kicks off....
  4. The final project in the chain is International Release Daily Build via SNOMED Release Service (snomed-release-service-daily-build) which picks up the files detected in step 1.

 

  • No labels