Search code examples
cruisecontrol.net

CCNetIntegrationStatus is always UNKNOWN when used in the publishers section


I have a build process running with CCNET v1.8.5. When the build completes, successfully or not I want to send a notification to Slack. I have the notification piece working with Slack's web hooks (see below) but I cannot seem to obtain the status of the current build via the CCNetIntegrationStatus property. The result of using $[$CCNetIntegrationStatus] in my config is always Unknown.

I have a hunch that the reason is that these CCNET integration properties (at least they way that I am declaring them) are processed and defined when the build starts. Of course, when the build starts the build status would be UNKNOWN.

I have also tried:

  • $[CCNetIntegrationStatus], the result is an empty/blank string.
  • $(CCNetIntegrationStatus), ccnet.config cannot be processed, variable not found
  • $CCNetIntegrationStatus, the result is the literal string $CCNetIntegrationStatus

Ultimately, what I want to achieve is to send an HTTP request (notification) once the build is complete that includes the current builds integration status, the prior builds integration status, the version number, and project name. How would I go about doing this?

Here is the sample configuration:

<!-- block definition to send slack notification -->

<cb:define name="SlackNotificationBlock">
    <checkHttpStatus>
        <httpRequest>
            <method>POST</method>
            <uri>$(slackUrl)</uri>
            <body> {{
                      "username": "Build Bot",
                      "icon_emoji": ":build:",
                      "attachments": [
                        {{
                          "fallback": "Warning! A New Build Approaches!",
                          "pretext": "Warning! A New Build Approaches!",
                          "color": "#D00000",
                          "username": "Build Bot",
                          "icon_emoji": ":build",
                          "fields": [
                            {{
                              "title": "Project",
                              "value": "$[$CCNetProject]",
                              "short": true
                            }},
                            {{
                              "title": "Version",
                              "value": "$[$CCNetLabel]",
                              "short": true
                            }},
                            {{
                              "title": "Status",
                              "value": "$[$CCNetIntegrationStatus]",
                              "short": true
                            }},
                            {{
                              "title": "Last Status",
                              "value": "$[$CCNetLastIntegrationStatus]",
                              "short": true
                            }},
                            {{
                              "title": "Location",
                              "value": "$(appUrl)",
                              "short": false
                            }}
                          ]
                        }}
                      ]
                    }}
            </body>
            <timeout>5000</timeout>
        </httpRequest>
    </checkHttpStatus>
</cb:define>

<!-- my publishers block -->
<publishers>
    <xmllogger/>

    <cb:scope slackUrl="url-to-slack"
              appUrl="application-url">
        <cb:SlackNotificationBlock/>
    </cb:scope>

</publishers>

Solution

  • I found a solution via the CCNetSlackPublisher. It accomplishes via a custom task what I was attempting to do entirely within the CCNET configuration syntax. Specifically, by implementing a custom task CCNetSlackPublisher is able to correctly obtain the current integration status. It then send that along to my configured slack channel. An additional benefit is that my CCNET configuration is simpler as well!

    I was never able to 100% confirm my hunch that the CCNetIntegrationStatus property is evaluated once when the build starts. However, given the behavior that I was seeing I believe this to be the case.