1

I have a Jenkins Pipline with three stages: "Build" "Test" and "Deploy".

Here is the problem I have with "Build":

The build step ensures that structure of the Control-M Automation API json files are valid.

To do this, I utilize the $endpoint/build service provided by Automation API in the build step:

        stage('Build') {
            environment {
                CONTROLM_CREDS = credentials('xxx')
                ENDPOINT = 'xxx'
            }
            steps {
                sh '''
                username=$CONTROLM_CREDS_USR
                password=$CONTROLM_CREDS_PSW
                # Login
                login=$(curl -k -s -H "Content-Type: application/json" -X POST -d \\{\\"username\\":\\"$username\\",\\"password\\":\\"$password\\"\\} "$ENDPOINT/session/login" )
                token=$(echo ${login##*token\\" : \\"} | cut -d '"' -f 1)
                # Build
                curl -k -s -H "Authorization: Bearer $token" -X POST -F "definitionsFile=@ctmjobs/TestCICD.json" "$ENDPOINT/build"
                curl -k -s -H "Authorization: Bearer $token" -X POST "$ENDPOINT/session/logout"
                '''
            }
        }
<snip>

Everything works as expected, but if I intentionally put an error in the json file, Jenkins detects it and prints the error in the terminal, but "Build" still goes green. Can anyone identify the error? My expectation is that the stage "Build" goes to red as soon as there is an error in the JSON file.

Here is a Jenkins output from the terminal:

+ password=****
++ curl -k -s -H 'Content-Type: application/json' -X POST -d '{"username":"xxx","password":"****"}' /automation-api/session/login
+ login='{
  "username" : "xxx",
  "token" : "xxx",
  "version" : "9.19.200"
}'
++ echo 'xxx",
' '"version"' : '"9.19.200"
' '}'
++ cut -d '"' -f 1
+ token=xxx
+ curl -k -s -H 'Authorization: Bearer xxx' -X POST -F definitionsFile=@ctmjobs/Test.json /automation-api/build
{
  "errors" : [ {
    "message" : "unknown type: Job:Dummmy",
    "file" : "Test.json",
    "line" : 40,
    "col" : 29
  }, {
    "message" : "unknown type: Job:Dummmy",
    "file" : "Test.json",
    "line" : 63,
    "col" : 29
  } ]
}+ curl -k -s -H 'Authorization: Bearer xxx' -X POST /automation-api/session/logout
{
  "message" : "Successfully logged out from session xxx"
} ``

1 Answers1

0

Jenkins in order to consider a stage as failed, it will check the exit code of a command executed, in your case

curl -k -s -H 'Authorization: Bearer xxx' -X POST -F definitionsFile=@ctmjobs/Test.json /automation-api/build

The issue is that the curl, as a command, is executed successfully. But the body of the curl indicates that the api call failed.

You could add --fail flag to your curl. This will force curl to return an erroneous exit code when the response status is > 400

(HTTP) Fail silently (no output at all) on server errors. This is mostly done to enable scripts etc to better deal with failed attempts. In normal cases when an HTTP server fails to deliver a document, it returns an HTML document stating so (which often also describes why and more). This flag will prevent curl from outputting that and return error 22.

curl --show-error --fail -k -H 'Authorization: Bearer xxx' -X POST -F definitionsFile=@ctmjobs/Test.json /automation-api/build
Tolis Gerodimos
  • 3,782
  • 2
  • 7
  • 14
  • ok understood. however, my research is unsuccessful right now, could you show me how that would look if an exitcode with 400 or 500 is created? –  Feb 08 '22 at 14:04
  • Updated the answer with an example and also added an alternative way. Check again – Tolis Gerodimos Feb 08 '22 at 14:52
  • First of all, thanks for your effort! I tried both variants, they work, where I think you made a mistake: `if [[ ${response_status} -gt 400 ]]` --> `400` is the error code I get. I have now entered `200` and so it breaks as expected. The problem with both variants is that the logs of Jenkins no longer say why `"Build"` aborted. Before it went through, but in the logs it was understandable which error it was. Now it cancels, but the error is no longer in the logs. –  Feb 08 '22 at 16:26
  • Update the answer with status code and a more robust logging. Is this what you wanted? – Tolis Gerodimos Feb 08 '22 at 17:16
  • No not really. Now there is an echo with `"Description of the failure"` in the log. See my initial post again. There it says in the log: `"error: unknown type Job:Dummmy"` This is the error I made on purpose. If I change the curl as you suggest, then the part is missing. –  Feb 09 '22 at 08:26
  • You are correct forgot to add the proper flag. Also Removed the first alternative since the second is more concise. Excuse me for the back and forth. Would you mind testing it again? – Tolis Gerodimos Feb 09 '22 at 08:45
  • Thanks, I tested it again and unfortunately the output is still not as requested: `"curl: (22) The requested URL returned error: 400"` I think the problem now, as you mentioned at the beginning, is that the error now refers to the curl command, but not to the body. –  Feb 09 '22 at 08:51
  • So the output stops directly after the error code of the curls command instead of outputting the body. –  Feb 09 '22 at 08:52
  • try removing the -s flag. Since it makes the output silent? Does the stage fail as intented? – Tolis Gerodimos Feb 09 '22 at 08:54
  • If I remove -s, there is an additional table in the output with Dload, Upload, Total Time, Time spent etc. Yes, either the stage breaks and I am missing the output, or the stage runs through with the correct output :D Totally confusing. –  Feb 09 '22 at 09:01
  • No help with the original issue but you could always put a one-liner into the Post Command field in the Control-M jobdef where you run something to pick up the failure and print, say, FUBAR. Then, in the Post-Processing tab, get Control-M to check the output (Specific Statement I think it's called) for FUBAR and turn the job to NOTOK when it matches. – Mark Feb 09 '22 at 22:49
  • I was able to solve the problem by simply using two curl calls. Once my old one, where the stage has run through and behind it yours, so both errors are displayed and the stage breaks off. If you edit that in your answer, I can accept that :). Thanks a lot! –  Feb 10 '22 at 08:37
  • @sharete since the question was "Jenkins pipeline stage build is green even though an error is present" the answer basically solved your problem, since the issue with the logging was not in the original question – Tolis Gerodimos Feb 10 '22 at 08:44