Build process upgrades
- Xavier Schildwachter
We have been using Jenkins servers to build various artifacts for Synapse (which are usually uploaded to JFrog’s Artifactory), as well as for operations (deployments on AWS, administrative tasks on Synapse etc.). Jenkins has served us well (and still does) but has a number of drawbacks. One issue is that significant knowledge (how to build components, more importantly how to deploy them (i.e. parameters to the jobs), as well as the history of changes to the infrastructure) is locked on these systems and not always clearly captured. Another drawback is that maintaining servers and applications (updating the OS, the various dependencies and Jenkins itself), requires some work.
In recent years, the capabilities of Github workflows has expanded significantly, to the point where all of IT’s infra is moving to the platform. The goal of this document is to explore how we could leverage Github for our builds first and foremost but also possibly for operations, with the goal of moving most of our workload to that platform and reducing the reliance on Jenkins servers.
Build processes
Core components
Job | Comment | Repository |
|---|---|---|
Multiple instances (dev builds, develop/release/prod) building from different branches and / or repos (developer branches). |
| |
Multiple instances (dev/release/prod) building from different branches and/or repos (developer branches). Has dependencies on running other builds (notably stackBuilder). Also have requirement of being run in the same VPC as the RDS instances. |
| |
Multiple instances (dev/release/prod) building from different branches. |
|
Dependencies
Common issues
Description | Comment |
|---|---|
Weekly modification to the builds (e.g. branches to build from) | Need to consider alternatives such as building from fixed branches (staging, prod, develop). |
Dependencies on information on the build systems | There are a number of parameters currently stored in ~/.m2/settings.xml. They would need to be stored (possibly encrypted) and passed to the builds in GH workflows. |
Saving artifacts to JFrog artifactory. | As now, using maven + crredentials (currently in .m2, see above), using action… Should we consider GH itself to store artifacts |
Need networks access to resources such as databases. | Need to investigate using remote runners (would run in the AWS VPC, with instance profile as Jenkins agents do now). |
Dependencies on operations jobs | Some builds depend on operations job to be executed (e.g. the repo builds require the corresponding shared resources to be deployed). All builds require the shared Synapse and IT infra to be deployed. Currently, everything is co-located on multiple Jenkins systems and has already lead to duplication of some jobs). Inter-build dependencies can be done with workflow_dispatch in GH but that would mean we need to move some operations jobs to GH as well. Alternatively, is there a way to trigger a Jenkins job from a GH workflow? |
Out of scope
Portals / BridgeDigital deployments (IT-1695, IT-3162)
Operations jobs (http://build-system-ops.dev.sagebase.org:8080, http://build-system-ops.prod.sagebase.org:8080)