[Buildmaster] Add queryable custom properties on a deployment level

[Anthony]

Hello to the community.

We use Buildmaster 7.0.23 to enable our customer to deploy artifacts.
The basic flow of a deployment looks like this: An Otterscript is triggered -> SHCall is invoked -> An in-house deployment tool is invoked.
The in-house tool returns a status code, and the SHCall in turn returns this status code to the Otterscript, which then is well known on its level.
The requirement is that this return code be returned to the client. The latter is making the deployment via the /api/releases/builds/deploy API (by submitting: applicationName, releaseNumber, buildNumber, toStage)
The client then checks the status of the deployment by calling /api/releases/builds/deployments, and obtains a DeploymentInfo object as documented in this page : https://docs.inedo.com/docs/buildmaster/reference/api/release-and-build#deploymentinfo-object.
In terms of deployment status, this object doesn’t contain much: just the “status” property, which can only take the values “pending”, “executing”, “succeeded”, ‘warned’, or “failed”.
In the Otterscript, I can control this value, at least between “succeeded,” “warned,” and “failed.” For example, by checking the return code and selecting one of these three values based on the return code.
But that’s not enough, I need to be able to give the client the possibility to get the returned code from the in-house deployment tool, which is known by the Otterscript.
This return code should be scoped at the deployment level.
How can I do this? Is there a way to modify the deploymentinfo object in OtterScript to add custom properties, such as a return code or any other useful information for the client ?

Thank you in advance for your help.
Anthony.

[atripp]

hi @Anthony ,

This sounds like a great use-case for variables; you can programmatically set them in OtterScript using an operation (check your /reference/operations page to learn what the name is, I think it was renamed in modern versions of BUildMaster), and then query them with the variables endpoint: builds/«application-name»/«release-number»/«build-number»

Here's a link to the documentation:
https://docs.inedo.com/docs/buildmaster/reference/api/variables

Cheers,
Alana

[Anthony]

Hi @atripp,

Thank you for your reply.
Using variables for custom properties seems like the logical approach, but the issue is that I cannot set a variable at the deployment level, hence my previous question about the deploymentinfo object.
For instance, the 'Set build variable' operation targets the build itself. Since a single build can involve multiple stages and several deployments, a build-level variable cannot represent a unique deployment execution. Any value set there would be overwritten or shared across all deployments of that build.
My goal is to store a specific value during the execution so the client triggering the deployment can read it back and verify if it completed successfully.
Is there a way to define Deployment-specific variables or Output parameters that persist only for a single execution? I would appreciate any alternative suggestions you might have.

Have a nice day,
Anthony.

[atripp]

Hi @Anthony,

I'm afraid not; the deploymentinfo is part of the BuidMaster API, and it's effectively reading data from the database that you'd otherwise see in the UI. Its fairly "disconnected" from runtime execution.

The only persistent (i.e. outside of runtime) variables are going to be configuration (i.e. Build-scoped) variables. I suppose one thing you could do is define multiple build variables (e.g. $MyTarget1=value, $MyTarget2=value2).

You could also store a map variable on the build, like %MyMap = %(MyTarget1: value, MyTarget2: value2) -- although that might involve a bit of awkward OtterScript to get working.

It's not a use case we designed for.

Cheers,
Alana

[Anthony]

Ok @atripp, thanks for getting back to me. I'll see if I can include the deployment ID and return code as key-value pairs in the build instead.

Have a nice day,
Anthony.