Diary on 2026-01-14

Pipeline for GHRA

This week, I am starting to support the GHRA team for their whole CI/CD pipeline. This is a new product; I need to set up the whole infrastructure from scratch.

Tasks including:

• BTP Global account for dev (in canary) and prod (live) landscape
• IAS tenant for authentication and authorization
• CI/CD pipeline using GitHub Actions
• Sonar/CodeQL/OSC/PPMS/CTP scanning setup
• Common repository

For this new application, Hyperspace suggests using GitHub Actions instead of Jenkins or Azure DevOps pipelines. So I followed the recommendation, but there are still some differences.

I cloned the official pipeline action repository piper-pipeline-action, and did some customization to it to meet our requirements.

First of all, from our experience, it is better to have a separate pipeline repository instead of placing the GitHub Action in the code repository, which will reduce the impact when developing the pipeline. The first thing is how to maintain the Piper config in the central pipeline repository. Referencing EMS, I stored the Piper config in the pipeline repo, but I still need to use a download/upload function to get the config remotely since GitHub Actions don’t have a function like libresource in Jenkins. For each stage, I need to add the download function after the code is checked out to make sure the Piper config exists.

Second, maintain the credentials in the Vault. I don’t want to save the credentials in the GitHub secrets; we already have Vault, so it is convenient to store the credentials in it, and our Piper toolset has built-in support.

Third, extend integration. The default integration stage doesn’t have a deployment step to deploy the app to a Dev/CI environment for testing, so I added the step. There is a trick: one env PIPER_PIPELINE_TEMPLATE_NAME to specify the stage template should be removed. Then add the cloudfoundryDeploy and sapDownloadArtifacts steps; it should work.

I also added 3 distinct workflows: one is a general CI/Release workflow, which does the normal build and release; the second is to do OSS and PPMS scans for security; and a third is a CTP scan for commercial software scanning. I can continue to improve this: integrate CTPScan into the OSS and PPMS workflow since they are doing similar things, and also change the trigger for it to be on a schedule.

To-Dos

There are a couple of things that need to be done:

• Create global account on live landscape and its CAM profiles
• Create CAM profiles for the BTP canary org and space
• Create CAM profiles for github
• Create CAM profiles for IAS
• Setup trust between IAS and BTP accounts
• Maintain wiki for all DevOps setup
• Implement CI and release stages,split them in separate workflow
• Setup OSC scanning after SCV is ready
• Setup Sirius for the pipeline