Add "tags" to project-area of Webhook Result JSON

Hi there,

please add tags to the project info that is contained in the Result-Webhook-JSON.

Upon reacting to an incoming webhook i would like to be able to decide my chosen path of action depending on the tags that are configured for a sonarqube project

Currently the Webhook-Result-JSON contains for project the following:

  • key : sonar.projectKey
  • name : sonar.projectName
  • url : (custom backlink to the analysis result in sq-server)

If a parameter “tags” would be added here inside projects block which contains a commaseparated list of tags that are configured for the analysed project … i could parse that and react to these.

Smth like this (see below) … only inside the projects tag, my paint skills were not enough to squeeze it into the projects-area :innocent:



Could you explain why you need this? What you want to do with it?



I guess my why (see quote below) was not inspiring enough?


  • You could envision something like “trigger some event for TagTeam 1 when an analysis result containing the tag tag1 is found” (totally no wrestling pun :ninja: )
  • You could envision some event as “send message to a defined channel”
  • Or any other action you would want to trigger by using a tag as triggering-filter ¯\_(ツ)_/¯


Ann, after having answered … i, still, am genuinely interested in the reasoning why you followed up with your question … i’d like to better understand your way of thinking here.

Are you checking if the precise action i want to trigger might be more easily archievable in a different way? Or did you maybe just skim over my quoted lines?

e.g.: why was my quoted explanation “not explaining enough”?


My thinking is

  • the relevant information would automatically be reflected back to the project’s team, who are probably the most qualified folks to take action
  • project tags just don’t change that much. You should be able to make whatever decisions are necessary based on the project itself

I’m just not getting what tag-based decision making adds here.


  • It is a second “discriminatory value” which is not unique like sonar.projectKey (and thus more changeable/ groupable/flexible)
  • It would already be present at the time of webhook consumation without having to query the WEB_API after Webhook delivery

==== Having said that …

  • i presented my suggestion
  • found a workaround via a query to WEB_API (api/components/show?component=my-projectkey)
  • found more complexity in “design-questions” like “if i add tags, why do i not add other project-relevant settings, too?”

I still would like to not need to perform a WEB_API lookup to retrieve tags, but i would also understand refraining from adding them to the WH-Result-JSON. It now looks more like “juggling where the complexities are handled” :man_shrugging:


Just to make sure… I didn’t present my thinking when I initially came back to you because I didn’t want it to seem like I was arguing with your need.

And I still don’t understand what actions you want to take based on tags. Would you mind sharing what actions you expect the teams to take?



actually, i have no clue (and it is not of my concern, either) what actions are to be expected to take.

Bluntly spoken: “Any action” … i do not care. :man_shrugging:

I just want to be able to create a Receiver for the Webhook Result which is able to discriminate between tags without performing another action (e.g. looking up the tags for the contained sonar.projectKey)

(but as i wrote earlier: i do not mind performing the additional lookup, i am able to query the WEB_API. But maybe someone else is not able to perform said lookup)