A list of builds to submit to Jira.
Each build may be associated with one or more Jira issue keys, and will be associated with any properties included in this request.
Optionalproperties?: Record<string, any>Properties assigned to build data that can then be used for delete / query operations.
Examples might be an account or user ID that can then be used to clean up data if an account is removed from the Provider system.
Note that these properties will never be returned with build data. They are not intended for use as metadata to associate with a build. Internally they are stored as a hash so that personal information etc. is never stored within Jira.
Properties are supplied as key/value pairs, a maximum of 5 properties can be supplied, and keys must not contain ':' or start with '_'.
OptionalproviderMetadata?: { product?: string }Information about the provider. This is useful for auditing, logging, debugging, and other internal uses. It is not considered private information. Hence, it may not contain personally identifiable information.
Optionalproduct?: stringAn optional name of the source of the builds data.
Optionaloptions: RequestOptions
Update / insert builds data.
Builds are identified by the combination of
pipelineIdandbuildNumber, and existing build data for the same build will be replaced if it exists and theupdateSequenceNumberof the existing data is less than the incoming data.Submissions are performed asynchronously. Submitted data will eventually be available in Jira; most updates are available within a short period of time, but may take some time during peak load and/or maintenance times. The
getBuildByKeyoperation can be used to confirm that data has been stored successfully (if needed).In the case of multiple builds being submitted in one request, each is validated individually prior to submission. Details of which build failed submission (if any) are available in the response object.