Feature: Route different notification types to different channels

[adamrtalbot]

Summary

Allow users to configure different Slack channels for different notification types — e.g., errors go to #pipeline-alerts, completions go to #pipeline-log, and per-task notifications go to a dedicated channel.

Motivation

Teams often want high-signal alerts (failures) in a monitored channel while keeping routine success notifications in a lower-priority channel. Currently all messages go to a single channel (or webhook), forcing teams to choose between noise and missing critical alerts.

Proposed Configuration

slack {
    botToken = 'xoxb-...'
    // Default channel for all notifications
    botChannel = '#pipelines'

    onStart {
        // Inherits default channel
    }

    onComplete {
        // Override channel for completions
        channel = '#pipeline-log'
    }

    onError {
        // Errors go to the alerts channel
        channel = '#pipeline-alerts'
    }

    onTaskComplete {
        channel = '#pipeline-tasks'
    }
}

Key Design Considerations

• Per-event channel override — each event config (onStart, onComplete, onError, onTaskComplete) can optionally specify its own channel, falling back to the global botChannel.
• Bot Token only — webhooks are tied to a single channel by design. Per-event routing requires the Bot Token approach. Document this clearly.
• Multiple channels for same event — consider whether a single event can post to multiple channels (e.g., errors go to both #pipeline-alerts AND DM the user). Could be a list: channels = ['#pipeline-alerts', '#oncall'].
• Webhook fallback — if using webhooks, log a warning that per-event channel routing is not supported and all messages will go to the webhook's configured channel.

Implementation Notes

• Add an optional channel field to OnStartConfig, OnCompleteConfig, OnErrorConfig
• In SlackObserver, pass the event-specific channel (or default) to BotSlackSender
• BotSlackSender.sendMessage() already posts to a channel — make this parameterizable per-call rather than fixed at construction
• Threading should still work within each channel independently

[FriederikeHanssen]

When we talked about it I thought this feature would be different channels for different events only. But now I see that it also includes Multiple channels for same event. this would be great for nf-core: alert the pipeline developer directly, but also send failures to a central channel for the infra team to monitor