Ideally I would love for #32 to happen, but if it is not possible right now, then I may have a workaround suggestion that will allow users to programmatically apply the plugin to all build configurations.
I notice that the settings we apply to all build configurations are currently stored inside config/slackIntegration.json in the form of a buildSettings map:
Here it seems that each key is a random string of 5 letters that are not useful, and also buildTypeId is using some sort of internal build ID "bt" + x, where x is a number that corresponds to how many total build configurations there are. For example, if I have 2 total build configurations and each are using the plugin, the buildTypeIds are bt1 and bt2. There doesn't seem to be a way to figure out which build configuration ID actually corresponds to these "btX" shorthands being stored in the settings file.
My proposal:
Use the real Build configuration ID defined in the "General Settings" page for each build configuration to keep track of which build configurations are using the plugin.
Ensure the plugins get automatically set up on build configurations that exist in the settings file.
This way, your users can write a quick REST API script to get a list of every build configuration they desire, and then they can use this list to programmatically restructure their slackIntegration.json file to apply the plugin to every build configuration.
The end result would be that simply by programmatically adding every build configuration to the settings file, the Slack plugin is automatically added to each of these configurations. Again, #32 is a much better solution, but this suggestion feels like significantly less work and would be a quick win.
Ideally I would love for #32 to happen, but if it is not possible right now, then I may have a workaround suggestion that will allow users to programmatically apply the plugin to all build configurations.
I notice that the settings we apply to all build configurations are currently stored inside
config/slackIntegration.json
in the form of a buildSettings map:Here it seems that each key is a random string of 5 letters that are not useful, and also
buildTypeId
is using some sort of internal build ID"bt" + x
, wherex
is a number that corresponds to how many total build configurations there are. For example, if I have 2 total build configurations and each are using the plugin, thebuildTypeId
s arebt1
andbt2
. There doesn't seem to be a way to figure out which build configuration ID actually corresponds to these "btX" shorthands being stored in the settings file.My proposal:
This way, your users can write a quick REST API script to get a list of every build configuration they desire, and then they can use this list to programmatically restructure their
slackIntegration.json
file to apply the plugin to every build configuration.The end result would be that simply by programmatically adding every build configuration to the settings file, the Slack plugin is automatically added to each of these configurations. Again, #32 is a much better solution, but this suggestion feels like significantly less work and would be a quick win.