DevOps validation for Cloud Integration worksflows
There are SAP customers who want to perform a validation of their iFlows before they are allowed to transport the content, so they can run external validation like CPILint or execute unit tests.
In Figaf we copy all iFlows to a Git repository. It is therefore interesting to be able to run a pipeline that performs validation of the setup. We added this in the 2306 release, and now improved it.
On the agent, select Integrate with Git Pipelines.
Figaf will then check for a file called
pipeline-validation.txt. If it contains a line with Exit code: 1, it will be shown as an error in Figaf, both when performing a transport and when checking status.Here is an example of how it can be used in GitHub Actions. It does require a bit of work to get working, and you should make your own attempt at getting it running. It will require that you know some Gradle and Git work.
How to get this working:
1. Add the
2. In a
gradle.properties to the Git repository.2. In a
.github/workflows you need to add the files. They are in the included ZIP file of the page, see bottom of page.3. Modify the
cpilint.xml to your needs for governance.4. Check the
5. Under Settings → Actions → General, make sure you select workflow permissions to Read and write. This is needed because Git needs to have access to run and commit the changes back into the repository. Notice there can be some difference if you run in your own repository versus in an organisation's repository.
figaf-validation.yml and make the necessary adjustments.5. Under Settings → Actions → General, make sure you select workflow permissions to Read and write. This is needed because Git needs to have access to run and commit the changes back into the repository. Notice there can be some difference if you run in your own repository versus in an organisation's repository.
What's new?
1. Run the validation on demand. Go to the Actions tab, select the Figaf Pipeline workflow in the sidebar, and use the Run workflow button. This is useful when you want to re-run all your CPILint rules and unit tests without waiting for a new synchronisation.
2. Results are easier to read. After a run, the summary page shows a table of each iFlow that ran tests, with its package, version, outcome and, for failures, the assertion that failed. Gradle's HTML reports are also uploaded as a downloadable artifact, together with a generated
test-summary.html at the top level that gives an overview of all packages and links through to each individual report.3. Cleaner Pipeline. CPILint 1.1.0 can inspect an unpacked iFlow folder directly using
-unpacked-files, so the pipeline no longer has to zip each flow before checking it. This version of CPILint requires Java 17, which the workflow now sets up.