Support Teams notification

[michaelsauter]

It would be nice if the finish task (or a separate task) could notify a Teams channel in case of build failure (or any kind of build result).

In Groovy we once had this POC:

def payload = """{
    "@context": "https://schema.org/extensions",
    "@type": "MessageCard",
    "themeColor": "c60000",
    "title": "Jenkins Build Failure",
    "text": "Build **${context.jobName} ${context.buildNumber}** failed!",
    "potentialAction": [
        {
            "@type": "OpenUri",
            "name": "Learn More",
            "targets": [
                { "os": "default", "uri": "${context.buildUrl}" }
            ]
        }
    ]
}"""
script.sh(
    label: 'Notify Teams Channel',
    script: """curl \\
        --fail \\
        -sS \\
        --request POST \\
        --header \"Content-Type: application/json\" \\
        --data '${payload}' \\
        ${teamsWebhookUrl}"""
)

[gerardcl]

hi! what about using the channels' email? that is for example what one can already do via Jenkins in the current ODS context. Mentioning it because of possible blocked functionalities due to corporate policies.

[michaelsauter]

@gerardcl good point - however sending emails is more complex to setup as you need a server to send emails from. I think we should start with a simple HTTP call and see if we hit limitations.

[gerardcl]

Totally agree, in any case I think we could also explore such option and provide a go function that already implements "net/smtp" or gomail "gopkg.in/mail.v2" go packages? so the server config could point to a corporate setup or AWS SES one within the ODS core config or per project even? just firing thoughts! :)

[kuebler]

@gerardcl @henninggross and I have been discussing how to approach this. It would be great to support several delivery mechanisms for notifications (e.g. Teams, e-mail, SMS, etc. come to mind). In that sense, we'd propose to have ods-pipeline just post to a configurable webhook destination (probably incl. a configurable API token) and let the webhook sort out the details of the concrete notification mechamism. That way, we don't enforce any particular messaging technology on ODS users and allow for some flexibility. In addition, ods-pipeline could provide examples how to use this functionality (e.g. AWS lambda or Azure Function that triggers an e-mail, Teams notification, integration services like Zapier/IFTTT, Vonage, ...).

[michaelsauter]

It would be great to support several delivery mechanisms for notifications (e.g. Teams, e-mail, SMS, etc. come to mind).

I like it, though I would see Teams/e-mail as immediate use cases. I cannot imagine how SMS would be useful, therefore I propose to keep this use case out of consideration in order to keep ods-pipeline minimal.

we'd propose to have ods-pipeline just post to a configurable webhook destination (probably incl. a configurable API token) and let the webhook sort out the details of the concrete notification mechamism.

Let me better understand this. Are you envisioning just POSTing to an URL configured by the user? Or creating a service that receives a POST from a Tekton task, and then this service calls to other services (AWS lambda, Teams API, etc.)? If the latter, who would create that service? Would that be part of the ODS installation? Would there just be examples of possible services?

[kuebler]

We'd just post to a URL the user specifies. It would then be the users responsibility to handle the request and trigger the actual notification. That way, we don't couple ods-pipeline to any particular kind of notification/technology.

[michaelsauter]

@kuebler Thanks for the clarification.

I think technically this is very elegant!

However, I want to trigger a discussion if this is the right fit for ods-pipeline:

• Tekton is a CI/CD framework, ods-pipeline is not. It is a specific implementation which comes with opinionated features/integrations. It should be extensible, but it shouldn't require you to come up with your own solutions.
• You can already POST to any URL you like by adding a separate finally task in your ods.yaml.

Basically, is the flexibility worth the downside that nothing is provided out-of-the-box, and therefore all users have to solve the problem for themselves? Maybe there should be at least be one thing that works out of the box?

[gerardcl]

totally agree, the problem is that we detected that in any case looks like this will not work out of the box, either because you have to setup an app in azure or setup an SMTP somewhere,... so maybe at the end it all comes to document examples on how one could have it?

[gerardcl]

Ok, @michaelsauter just pointed out a good to check link from official ms docs which is the base of the description of this issue. We will check if this still works on our end and continue from here!

[kuebler]

After discussing with @gerardcl, maybe implementing both, SMTP as a vendor-neutral protocol and Microsoft Teams as a more specific notification mechanism would make sense. If we make both of them pluggable, we'd make it "batteries-included" and still allow for a non-Microsoft stack as well.

[michaelsauter]

FWIW, here's an idea I had:

Note how the example code at the top has a payload with only few variables (URL, pipeline name, result). You could potentially embed a "payload template" in a ConfigMap, and replace variables inside it before we make a POST call from ods-finish. That allows users to adjust the payload, making integrating with other APIs that respond to POST/JSON possible and not tying this to MS Teams.

[gerardcl]

webhook here we go! 👍

[kuebler]

Love the approach with the template, was wondering though if there is a usecase for even more flexibility: With a single ConfigMap we‘d only be able to use one template across all Pipelines in the namespace (unless we make the ConfigMap‘s name itself configurable, of course). Would it make sense to allow for per-pipeline templates and webhook URLs (e.g. posting notifications to different teams channels on a repo by repo case comes to mind)? Or would this be overengineering/overcomplicating matters?

[gerardcl]

I like the idea @kuebler ! in any case, I would go on a step by step approach (keeping such idea in mind) and first start with simplest option

[michaelsauter]

Would it make sense to allow for per-pipeline templates and webhook URLs (e.g. posting notifications to different teams channels on a repo by repo case comes to mind)? Or would this be overengineering/overcomplicating matters?

I would also like to start with per-project first and wait with expanding further until enough people complain. I think the path forward towards multiple ConfigMap resources is clear enough, allowing us not to think more about it right now.