add support for bamboo specs

[Prem Chudziński]

configuration could use Deployment Project & Environment Name instead of ID

The IDs are unknown during bamboo specs creation, so it's not possible to add it.

.triggers(new AnyTrigger(new AtlassianModule("com.atlassianlab.bamboo.plugins.bamboo-after-deployment-trigger-plugin:afterDeployment"))
                    .name("After deployment")
                    .configuration(new MapBuilder()
                            .put("deployment.trigger.afterDeployment.deploymentProjectId", "**11173889**")
                            .put("deployment.trigger.afterDeployment.deploymentEnvironmentId", "**10977314**")
                            .build()))

[Alexey Chystoprudov]

Support of third-party triggers is not implemented in Bamboo yet. It's on our roadmap with middle priority. Team measures market demand on this feature. Once it will be possible to implement such functionality at plugin level it will be added.

[Prem Chudziński]

The code above has been generated using Bamboo itself so its supported. The plugin itself could use

.put("deployment.trigger.afterDeployment.deploymentProjectName", "PROJECT_NAME")
.put("deployment.trigger.afterDeployment.deploymentEnvironmentName", "ENV_NAME")

Wouldn't that work?

[Alexey Chystoprudov]

Code is generated by Bamboo and plugin can't control this process. Bamboo just takes internal configuration and exports to code. Usage of project and environment name is fragile to renaming

[Prem Chudziński]

Sure that's right but bamboo specs assumes that you define plan configurations upfront.

So either the bamboo spec API will have to return created object to be able to pass ID further on or add-on's as yours will have to use Names instead of ID to make it compatible.

[Alexey Chystoprudov]

You're right, Bamboo Specs code has 4 parts: Builder, Properties, Exporter/Importer and CodeEmitter. Right now only Exporter/Importer part can be provided by plugin. When I say about plugin control over Bamboo Specs generator I mean option to have Builder, Properties and CodeEmitter at plugin side. It will allow plugin to store its configuration with environment ids, but generate Java code which uses names

[Simon Graham]

I ran into exactly the same issue. To confirm, is there any way in the specs API to determine the deployment ProjectId or deployment EnvironmentId for another project? Are there any existing workarounds / hacks? We're highly dependent on the After Deployment trigger. Hopefully this soon becomes an integral part of Bamboo.

[Alexey Chystoprudov]

@latitude37s , there's no Specs API to get deployment project/environment id. You can try /quicksearch REST endpoint to fetch deployment project id by name https://docs.atlassian.com/atlassian-bamboo/REST/6.4.1/#d2e346

[Alexey Chystoprudov]

https://jira.atlassian.com/browse/BAM-19841

[Valeriy Pogrebitskiy]

Another issue with using IDs ('deploymentProjectId', 'deploymentEnvironmentId', as well as direct .oid() calls generated by specs extractor) - is that whenever original object is rebuilt (deleted / recreated), new object IDs are assigned. This entirely "breaks" all plans that are built with dependencies on the original object IDs. I am not positive, but same issue may also occur when original build and/or deployment plan gets rebuilt from specs. My team is in the process of converting existing Bamboo plans to specs - where we rebuild plans using repository-stored specs that we extract (first) from existing plans and edit them to follow certain standards that we have established; once plan's specs are ready - we rebuild the plan... which may (possibly) cause new object ID's being assigned to these plans. While doing so - we have already ran into issues with Branch Plans (that are not being rebuilt when master plan is rebuilt)...

I have seen this actually happen - and fully support requirement to transition to NAMEs vs. IDs. Any dependency on (reference to) a hard-coded object ID is extremely error prone and unreliable ...

[Former user]

Hey, Really great plugin.

Are you looking to put this plugin in the YALM Spec version?

[Alexey Chystoprudov]

Hi Rafael,

There’re no plans to add YAML Specs support for this plugin in recent future. It will be reconsidered if we bundle plugin with Bamboo

[Alexey Chystoprudov]

resolved at version 0.7 compatible with Bamboo 7.2+