Slack Webhooks no longer support `channel` and `username` except in legacy webhooks.

[sastorsl]

Describe the bug

When configuring notifications to slack the documentation specifies that you can set the channel and username.
Also detailed in the API spec

Slack have moved their old webhooks into legacy in favour of App based webhooks

Steps to reproduce

1. Configure a new Slack webhook, which must be set to a specific channel, and created in an app with an automatically created "bot" / user.
2. Configure a Provider.notification.toolkit.fluxcd.io/v1beta1 of type: slack and specify another channel
3. Observe that logs are sent to the webhook channel

Expected behavior

The "legacy" behavior of Slack was to be able to send to any channel.

While legacy webhooks are still available they are scheduled to be removed.

You're reading this because you're looking for info on legacy custom integrations - an outdated way for teams to integrate with Slack. These integrations lack newer features and they will be deprecated and possibly removed in the future. We do not recommend their use.

Screenshots and recordings

N/A

OS / Distro

OpenShift

Flux version

v0.35.0

Flux check

► checking prerequisites
✗ flux 0.35.0 <0.36.0 (new version is available, please upgrade)
✔ Kubernetes 1.23.5+8471591 >=1.20.6-0
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v0.25.0
✔ image-automation-controller: deployment ready
► ghcr.io/fluxcd/image-automation-controller:v0.26.0
✔ image-reflector-controller: deployment ready
► ghcr.io/fluxcd/image-reflector-controller:v0.22.0
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v0.29.0
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v0.27.0
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v0.30.0
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta1
✔ buckets.source.toolkit.fluxcd.io/v1beta1
✔ gitrepositories.source.toolkit.fluxcd.io/v1beta1
✔ helmcharts.source.toolkit.fluxcd.io/v1beta1
✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1
✔ helmrepositories.source.toolkit.fluxcd.io/v1beta1
✔ imagepolicies.image.toolkit.fluxcd.io/v1alpha1
✔ imagerepositories.image.toolkit.fluxcd.io/v1alpha1
✔ imageupdateautomations.image.toolkit.fluxcd.io/v1alpha1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1beta1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta1
✔ receivers.notification.toolkit.fluxcd.io/v1beta1
✔ all checks passed

Git provider

N/A

Container Registry provider

N/A

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[makkes]

Thanks for raising this. Quick question for clarity's sake: Do you know whether it's still possible to create the legacy webhooks?

[makkes]

@sastorsl in reference to

Observe that logs are sent to the webhook channel

Can you paste an excerpt of the logs you're seeing? Ok, I was actually to reproduce it myself: notification-controller dispatches the event to the Slack webhook and it lands in the channel that the webhook has been defined for so the .spec.channel field just gets ignored.

The only thing I see we can do about this is to document this better since the .channel field is part of the general Provider spec.

[sastorsl]

Do you know whether it's still possible to create the legacy webhooks?

We definitely have legacy webhooks working still. We discovered it when one of our users got disabled as a Slack user and one of their really old webhooks got disabled in the process.

Our Slack admin tells me it's possible to create a legacy webhook still, but it is of course living dangerously.

For some workload it's nothing more than a chore, that is creating a lot of webhooks and reconfiguring for the proper channels.
But we also have users being able to send alerts to custom channels where this is a bigger issue - if those webhooks are disabled down the line.

[sastorsl]

The only thing I see we can do about this is to document this better since the .channel field is part of the general Provider spec.

I agree.