Only send a notification based on some condition.

Pure Krome's Avatar

Pure Krome

09 Oct, 2017 05:59 AM

Hi AV,

we prefer using WebDeploy instead of Environment -> WebDeploy when deploying our website because we prefer the instant feedback instead of a separate process handling the deployment.

So, with this context, is it possible to only send a Slack notification if one of the conditions is met? In our scenario, we only want to send a slack if some environmental variable equals "some value".

For example:

      - dev
    - provider: WebDeploy
      server: $(deployServer)
      website: $(deployWebsite)
      username: $(deployUsername)
      password: $(deploySecurePassword)
      remove_files: true
      app_offline: true
      skip_dirs: \\App_Data

    - provider: Slack

and in this case, we only send a slack notification if $(deployUsername) -eq "PureKrome" (for example). (NOTE: we set this environment variable in the UI, per AV project .. so this means we have the one file in the repo but each AV project is per person)

Is this possible? What about if we manually fire some special powershell command, in .. maybe ... a deployment_success or on_success step?

e.g. -ps: AppVeyorSendSlackNotification token channel template


  1. Support Staff 1 Posted by Ilya Finkelshte... on 09 Oct, 2017 03:36 PM

    Ilya Finkelshteyn's Avatar

    We do not have a built-in feature to send notification on some specific conditions other than build success, failure or status change. So yes PowerShell sending Slack notification is a way to go. Slack API is very clean an straightforward, so it should not be a problem. Please look at this sample, but sure token should be a secure variable in your case. Good place to call this script in build pipeline is after_deploy step.

  2. 2 Posted by Akos Kiss on 23 May, 2018 11:12 AM

    Akos Kiss's Avatar


    just found this discussion as I'm facing a similar challenge. However, my goal is to comment on GitHub issues conditionally via the GitHubPullRequest notification provider. The emphasis is on conditionally, i.e., not for all successful builds.

    Is this possible anyhow?


  3. 3 Posted by Akos Kiss on 23 May, 2018 05:28 PM

    Akos Kiss's Avatar


    I've been typing my above comment hastily and made an error: my goal is to comment conditionally on GitHub pull requests, of course.

    BTW, I've also found this discussion: . A generic on:-based approach would be great, e.g., one that could check the value of an environment variable as shown in the deployment part of the reference yml at

      - provider: Environment
        name: staging
          branch: staging
          env_var1: value1
          env_var2: value2

    But for notifications, of course. Something like:

      - provider: GitHubPullRequest
        on_build_success: true
          my_env_var: 1
          # assuming that I've managed to set an env var during the build
          # e.g., using the build worker API

    So, what do you think, is this too far-fetched of an idea?

  4. Support Staff 4 Posted by Ilya Finkelshte... on 23 May, 2018 11:10 PM

    Ilya Finkelshteyn's Avatar

    There is a fundamental issue with this approach. Notifications are (at least now) build-level setting. However the same environment variable can have different value across different jobs inside the same build. Not sure which one is supposed to be trusted.

    Regarding GitHub Pull Request it does not fire on builds that are result of push, only in PRs. Or you need more granular control?

  5. 5 Posted by Akos Kiss on 23 May, 2018 11:38 PM

    Akos Kiss's Avatar

    Yes, it would be great to have more granularity in some sense. Let me outline the envisioned use case: there are some "regular" build jobs that are always executed and there is one job that is conditionally executed: it checks whether an opt-in string is present in the commit message early in the init phase and exits (either with success or with failure, it's irrelevant for now) if it's not there. But if it's there, it compiles some info via the build worker API into the job's messages and these messages get commented to the PR using the GitHubPullRequest notification provider.

    The why: Obviously, it would be an easier option not to go for an opt-in approach and always run the message-creating job but that would generate too many comments on a PR that gets updated multiple times (e.g., because of multiple review rounds). That would annoy developers, which would lead to the disabling of the whole notifications thing.

    The problem: Right now, I can only disable the "extra" job but not the sending of the notifications. So, even if the messages are not generated, an empty comment gets posted anyway.

    Here is a version of the yml configuration:

    And here is the concept tested:

  6. 6 Posted by Akos Kiss on 24 May, 2018 09:49 AM

    Akos Kiss's Avatar

    Well, there seems to be a workaround but it's not the nicest one. It turned out that during previous variants of the configuration the message was only visually empty, it contained \n\n\n\n". With some reorganization of the template I could really make the message an empty string, which caused GH to reject the comment. The job now has an extra log entry stating that (

    Error sending GitHubPullRequest notification: Error commenting on GitHub pull request: {"message":"Validation Failed","errors":[{"resource":"IssueComment","code":"custom","field":"body","message":"body cannot be blank"}],"documentation_url

    Effectively, this makes the notification conditional so it works for now but it's a bit of an abuse of the GH API. It might be more polite to check for empty messages and do the rejection of the notification on AV side.

  7. Support Staff 7 Posted by Ilya Finkelshte... on 24 May, 2018 05:37 PM

    Ilya Finkelshteyn's Avatar

    Nice hack :) Actually we had a discussion yesterday regarding more general plans to implement better coordination/chaining between jobs. And as part of this plan we realized that we have to implement job-level notifications. No ETA yet, but this is what we plan to work on it this year.

  8. 8 Posted by Akos Kiss on 24 May, 2018 10:22 PM

    Akos Kiss's Avatar

    Great, looking forward to announcements.

  9. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:28 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac