-
Suggestion
-
Resolution: Duplicate
-
None
Here is an excerpt from Bamboo's REST API documentation. It describes the URL you would hit in order to see things about a build result, such as logEntries.
https://docs.atlassian.com/bamboo/REST/5.0-SNAPSHOT/#d2e428
The emphasis is mine.
/result/{projectKey}-{buildKey}-{buildNumber : ([0-9]+)|(latest)}?expand&favourite&start-index&max-results
resource-wide template parameters
| parameter | value | description |
|---|---|---|
| buildNumber | string | buildNumber (numeric value or 'latest') |
| buildKey | string | plan key (might be simply planKey or composite planKey-jobKey) |
| projectKey | string | project key |
Methods
GET
Provide build result specified by projectKey-buildKey-buildNumber. Build number may be specified also as "latest" for latest result.
request query parameters
| parameter | value | description |
|---|---|---|
| expand | string | expands build result details on request. Possible values are: changes, metadata, artifacts, comments, labels, jiraIssues, stages, logEntries. stages expand is available only for top level plans. It allows to drill down to job results using stages.stage.results.result. logEntries and testResults are available only for job results |
| favourite | boolean | filters build results list to show only results for favourite plans. Works only for authenticated user |
| start-index | int | start index for results list (zero based) |
| max-results | int | maximum size for returned list |
available response representations:
- 404 [expand]
- 200 - application/xml, application/json (resultDetails) [expand]
- 401 [expand]
The problem here is that the most vital information is obfuscated behind some opaque terms. If you want to get logEntries from bamboo, you need to know that logEntries are only available for jobs. You then need to know how to provide a job in the query string. Presently, you would have to be forgiven for not knowing or realising that a buildKey actually can contain a jobKey.
Please consider rewriting the documentation such that the places a jobKey can appear are much more obvious.
Please also consider splitting the documentation up a little to distinguish the URLs where specific data is available. For instance, the above section should really be two sections: one for the non-job-specific information (which would exclude logEntries etc.) and then another section for the URL with a job in it, which would talk about the job-specific information available.