FR: Notifier Templates and Bindings

[LOZORD]

Hello from the Cloud Build team 👋

We are aware that many Notifiers users would like to have custom templating and config bindings available to make their notifications more useful. Our product team and I are working on a requirements doc for these features that we plan on releasing here to open up the coding of this feature to the public.

I'll respond here with the doc once we have it in a good state.

[iamyojimbo]

Hey @LOZORD, any movement on this?

[LOZORD]

Hi Savvas, unfortunately I can't give an update as I no longer work on Cloud Build. @Saaarah might have a better idea.

[jakebiesinger-storyhealth]

Friendly ping on this, @Saaarah.

We're heavy users of cloud build and Slack and our notifications look like garbage and are really hard to tell apart:

We use cloud build + Slack notifications for:

• automated nightly deployments to test environments
• automated daily e2e tests (dev, staging)
• automated code/vulnerability scanners (on several branches)
• to notify about manual deployments as they happen / are successful (dev / staging / prod / demo / etc)
• pull requests (which don't notify)

If standardizing this is too much to take on now, WDYT about just letting the various projects do their thing? We already have implementations ready but which are bitrotting like https://github.com/GoogleCloudPlatform/cloud-build-notifiers/pull/91

Or how about we just start with something simple like "subject/title + body in plaintext" for the payload?

[mikesoule]

I noticed this part of the official statement from the Cloud Build Team:

...we plan on releasing here to open up the coding of this feature to the public.

So the community is expected to do the work of building this feature (no prob there, that's what open source is) but we're stuck indefinitely waiting for Google to publish a list of requirements.

This is inconsiderate of both the contributors and the users. Please either truly open this up so we can get community contributions merged in or raise the priority on publishing a list of requirements. I'm sure the community would be happy to collaborate in regards to creating the requirements in the interest of ensuring all notifiers follow a standard.

From what I've read, it seems the hold up centers around the fact that the message published to Pub/Sub doesn't contain information about the trigger or placeholders to add such information. I assume that's a problem because changing the message format might break existing integrations. If this is the case, why not just plan on publishing the data we need for custom messages to a separate queue?

Here's a proposal for the message format to get us started.

{
    "project": "my-gcp-project",
    "buildId": "91bc6340-0ce4-4789-aeaa-fbaf6a398552",
    "duration": "1:45",
    "images": [
        "gcr.io/my-gcp-project/my-app:latest"
    ],
    "source": "repo/my-app",
    "trigger": {
        "name": "my-build-trigger",
        "repository": "repo/my-app"
    },
    "notifier": {
        "customPlaceholders": {
            "myPlaceholder": "Some value",
            "anotherPlaceholder": "Another value"
        },
        "template": "This is my go template for {{.trigger.build}} with {{.myPlaceholder}} and {{.anotherPlaceholder}}."
    }
}

[cristian-moreno-ruiz]

Any plans on moving this forward? We are using Cloud Build and have 10+ microservices, in different environments (staging, prod, etc). It would be really helpful to be aware of which of the services was deployed.

Thanks!

[wyardley]

Would be very useful to have this.

Also, I'd also suggest that it would be nice to have a simpler, container-based notifications that could either be directly part of Cloudbuild without creating any other resources, or a container based notification setup be embedded directly into workflows (similar to the Slack orb for CircleCI - https://circleci.com/developer/orbs/orb/circleci/slack).

Currently, the number of resources to setup and manage to get this working is quite a hassle for something that IMO should just be a builtin feature. The fact that the actual notifications themselves are not templatable or useful makes it even worse.

[omrta-dev]

Is there any progress on this, as others have stated the current notifications are kind of useless as they still require someone to view the logs to find out what service broken. In cases where multiple builds are failing, some of which are more/less important than others it would be very helpful to have some basic information added to the build notifications. Is there any work pending on the cloud build message that gets sent or work implementing the templating for the message?

[mikehardenize]

I'm amazed this was released without this functionality. Completely useless. Now I need to back it all out again.

[nbellamy-paper]

I see this commit 8 days ago https://github.com/GoogleCloudPlatform/cloud-build-notifiers/commit/b0668daa20c1f653e240545f8a289f12b027fab1

Does that mean that work is in progress for this?

The slack notifications are almost useless with the build ID instead of the friendly name.

[fragoulis]

https://github.com/GoogleCloudPlatform/cloud-build-notifiers/issues/32#issuecomment-1152328261