-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Omitting room
from Slack JCasC configuration leads to "java.lang.IllegalArgumentException: Project Channel or Slack User ID must be specified."
#857
Comments
After 27693a6, the Slack plugin fails to send messages on new Jenkins instances with: java.lang.IllegalArgumentException: Project Channel or Slack User ID must be specified. This seems to be due to some bug in the plugin where without a `room` setting, it doesn't know to rely on the default room associated with the token. This is filed upstream in: jenkinsci/slack-plugin#857 Short-term, let's just work around this by specifying an empty `room`.
After 27693a6, the Slack plugin fails to send messages on new Jenkins instances with: java.lang.IllegalArgumentException: Project Channel or Slack User ID must be specified. This seems to be due to some bug in the plugin where without a `room` setting, it doesn't know to rely on the default room associated with the token. This is filed upstream in: jenkinsci/slack-plugin#857 Short-term, let's just work around this by specifying an empty `room`.
Is there a reason you aren’t specifying a room? While web hooks do work some functionality won’t work with them. |
We use the same JCasC config to bring up multiple instances of Jenkins for different pipelines. They each send notifications to different Slack rooms and have their own separate tokens. We've been able to avoid having to conditionalize/templatize JCasC configs so far to keep things simple. Everything seems to work, so we're not using any functionality of |
but you can just create one bot user, and one token. invite the bot to the room and then override the room as you need it. a room in your slack send config is a lot clearer than a token |
We're trying to avoid adding more configuration than needed to differentiate between the pipelines. It's really nice right now that we don't have to specify the room each time we |
it's accidental, and as far as I know the webhooks you are using are likely deprecated: don't you currently need to provide configuration to override the token? or are you doing that at a folder level? |
Ahh, that's unfortunate. In that case we'll have to throw more configuration at it. It's confusing though, because when you set this up on the Slack app side, it asks for a channel to post to. Is there any purpose to that?
We're using the Jenkins CI app in Slack and get the token it generates from there. Is that using the legacy webhooks API?
The Jenkins credential is named the same (so is embedded in the generic JCasC dropin), but it's created differently per-pipeline. |
no that's not the webhooks one that's the legacy slack built-in one. |
Jenkins and plugins versions report
Environment
What Operating System are you using (both controller, and any agents involved in the problem)?
Jenkins running on OpenShift Container Platform 4.11.
Reproduction steps
room
key. E.g. the minimal config would be:slackSend
from a pipeline without specifying a channelExpected Results
Slack message goes to default channel associated with token.
Actual Results
Anything else?
It appears that this is fixed by just adding
room: ""
to the JCasC config. Another way to work around this is to go to the Jenkins configuration page and just save it without changing anything; an emptyroom
tag will be added to the Slack config on-disk.So it sounds like there might be faulty logic somewhere that distinguishes between a
null
vs empty string for the room when it shouldn't.The text was updated successfully, but these errors were encountered: