Skip to content
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

SlackNotifier message notification popup says "no preview available" in Slack desktop client for Windows #180

Open
andre-engelbrecht opened this issue Jul 11, 2023 · 5 comments

Comments

@andre-engelbrecht
Copy link

I've setup the SlackNotifier in my GCP build pipeline, everything is working pretty well but when messages come through in the Slack desktop client for Windows, the notification popup says "no preview available" even though the actual message in Slack appears fine.

enter image description here
enter image description here

This seems to be due to the fact that in the WebhookMessage post, the "Text" property is not included and Windows / Slack (on Windows) not supporting rich-text content. Slack documentation suggests including the "Text" property in the payload which will be used as fallback when rich-text is not supported.

More details are available in the StackOverfow issue I posted: https://stackoverflow.com/questions/76657027/google-cloud-build-slack-notifier-message-no-preview-available

The posted answer explains the (suspected) problem and solution and he even created a fork with suggested code changes - onix@e83dab3

@jkumara
Copy link

jkumara commented Oct 24, 2023

It would be great to get this solved!

@scr4bble
Copy link

scr4bble commented Apr 11, 2024

I am getting the same thing [No preview available] in notification inside Fedora linux (using web browser slack app) and the same also applies to android mobile slack application.

Our slack json looks like this:

[
    {
        "type": "section",
        "text":
        {
            "type": "mrkdwn",
            "text": "Cloud Build in *{{.Build.ProjectId}}* for service *{{.Build.Substitutions._SERVICE_NAME}}* has finshed with status *{{.Build.Status}}*"
        },
        "accessory":
        {
            "type": "button",
            "text":
            {
                "type": "plain_text",
                "text": "Build Logs"
            },
            "value": "click_me_123",
            "style": "primary",
            "url": "{{.Build.LogUrl}}",
            "action_id": "button-action"
        }
    }
]

@universal-jewellery
Copy link

Same on MacOS 13.7.1 with Slack 4.41.105.

Looking at what returned here it would seem "Blocks" are catered for your slack.json as well as the colors outlined here. What we would also need is a way to pass in a text string which would act as your preview text.

@universal-jewellery
Copy link

universal-jewellery commented Jan 16, 2025

Same on MacOS 13.7.1 with Slack 4.41.105.

Looking at what returned here it would seem "Blocks" are catered for your slack.json as well as the colors outlined here. What we would also need is a way to pass in a text string which would act as your preview text.

Looking at the data available. We have tmplView which contains the Build object. Assuming the slack-go client is able to accept Text: <string> it in theory it could be modified it so that any string Build properties could occupy that string... OR we could set up a dedicated ENV or similar in the yml that would take precedence if set - we also have access to Build in the string could be templated there.

@universal-jewellery
Copy link

Same on MacOS 13.7.1 with Slack 4.41.105.
Looking at what returned here it would seem "Blocks" are catered for your slack.json as well as the colors outlined here. What we would also need is a way to pass in a text string which would act as your preview text.

Looking at the data available. We have tmplView which contains the Build object. Assuming the slack-go client is able to accept Text: <string> it in theory it could be modified it so that any string Build properties could occupy that string... OR we could set up a dedicated ENV or similar in the yml that would take precedence if set - we also have access to Build in the string could be templated there.

Which all looks exactly like its been taken care of by this PR already:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants