In this blog we will take a look at how to run your ABAP Unit tests in CI pipeline when publishing from AbapGit.
There are some really cool stuff already in this area such as:
lars.hvamblog about running ABAP code in Githut actions without an ABAP stack
andreas.gautschblog about his Eclipse plugin for ADT
felipe.dimmu23blog about monitoring Abap packages in pipelines
The difference between Felipe's blog and mine is that in this blog I will explain how to run the unit tests without relying on additional source code installed on the Abap server.
Why would you even want to consider this approach. You could just keep running your Unit tests like normal.
While this is certainly true, I don't think you can test too often, so adding another layer of testing in a pipeline where you could also integrate other packages as well is pretty cool. Or possibly you could use this setup to potentially shift your development to a server off the common transport path (See graham.robinson's blog for inspiration) to later integrate into the test system via a pipeline.
Let me explain my setup for this blog, everything is running in separate Docker containers.
The stages section of the yml file is to indicate that the jobs are to be run sequentially and not in parallel
stage: abap_unit <=which stage does the job belong to
- npm install -g abap_test_runner_cli
- echo "$( abaptr --skip_image true )" >> test.txt <=Take the output from the abaptr command and copy into a text file called test.txt
artifacts: <=Tells the pipeline that new files are to be stored in the context of the pipeline, in this example the text file test.txt
- apt-get update <= Update the package manager as we will install python3. I'm to lazy to find a docker image that has both node and python 🦥
- apt-get install python3 -y <= Install python3
- |- <= Execute a multi line command
if [[ $( grep -q 'Error' test.txt && echo true || echo false ) == true ]]; then <= The if statement uses a grep query command to check for the word Error in test.txt, if present it evaluates to true, otherwise false
echo "Creating issue"
curl --request POST --header "PRIVATE-TOKEN: $private_token" "https://gitlab.agilux.com.au:44388/api/v4/projects/$CI_PROJECT_ID/issues?title=Unit%20test%20failed&description=$(cat test.txt | python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.stdin.read()))")" <= The curl command creates the issue via the API. We set the title Unit Test Failed and the description from the test.txt file URL encoded using the python3 command. The private_token is a personal access token stored in the CI variables. This isn't best practice, but for demo purposes and since i'm the only user on this gitlab instance, i'll let that little security issue pass 🙈
exit 1 <= Tell the pipeline to fail
- abap_unit <= Tell the job that it needs the artefacts coming from the abap_unit job.
Now when we run our abap_unit job will always execute as success, but the second will validate the output from the abap_unit job and decide whether to create an issue or not.
Checking the new pipeline we can see that the first job passes now as expected, but second fails.
And upon checking our issue log, we now have a newly created issue
Text looks a bit weird as Gitlab expects markdown formatted text, but currently it's not.
You could take a look at pandoc to handle that.
Also if you want to see the actual test output as well, then add the line
cat test.txt before the exit 1 line.
You could also assign the user to the issue automatically by adding the parameter assignee_id=$GITLAB_USER_ID to the curl command.
I hope you enjoyed this little nerdy read. Hopefully it's inspiring you to take a closer look at this if you are already using AbapGit or maybe an inspiration to get started.