New endpoint: GET /apps/{APP-SLUG}
1 Like
New endpoint: get log info & “raw” / full log: GET /apps/{APP-SLUG}/builds/{BUILD-SLUG}/log
1 Like
Do we have an eta for an endpoint that we can get build artifacts from?
1 Like
Yes, the ETA for this feature is about the end of this week
2 Likes
Update: the build related endpoints now return additional properties of the build (see this diff).
New endpoints, including the artifacts ones are coming really soon!
Note: the stack_identifier returned by these endpoints is null in every case right now, that will be fixed ASAP early next week.
1 Like
Additional App Data properties added: https://github.com/bitrise-io/devcenter/pull/143/files#diff-e2076cdaef033c5b92fa4c518effdb8aR142
Note: repo_slug might be removed, and repo URL will definitely be added soon.
Fixed, the stack ID is not returned for the builds.
I would just like to throw my/our hat in the ring and state that having access to the artifact (and as an added bonus: the dysm file(s)) would be incredibly useful for us 
1 Like
@blackswandev & @DerekHunterIcon API endpoint for the Artifacts is almost done, it was unfortunately delayed due to some restructuring / revisions, but should be the next endpoint along with enable/disable public page for installable artifacts.
1 Like
Thanks for the update! I look forward to it.
1 Like
@blackswandev & @DerekHunterIcon - artifacts list, show & download endpoints are now ready; we’ll fix the DevCenter docs but the format won’t change - you can find the related docs PR here: https://github.com/bitrise-io/devcenter/pull/148/files#diff-e2076cdaef033c5b92fa4c518effdb8aR427
1 Like
New endpoint is available: List artifacts for a certain build
Documentiation: http://devcenter.bitrise.io/api/v0.1/#get-appsapp-slugbuildsbuild-slugartifacts
1 Like
New endpoint is available: Retrieve a certain artifact
Documentiation: http://devcenter.bitrise.io/api/v0.1/#get-appsapp-slugbuildsbuild-slugartifactsartifact-slug
1 Like
New endpoint is available: Set is_public_page_enabled attribute of a specific artifact
Documentiation: http://devcenter.bitrise.io/api/v0.1/#patch-appsapp-slugbuildsbuild-slugartifactsartifact-slug
2 Likes
New endpoint: Abort a build.
http://devcenter.bitrise.io/api/v0.1/#post-appsapp-slugbuildsbuild-slugabort
It doesn’t look like we can control if the abort is reported as a success or failure on GitHub?
@bootstraponline you’re right, we’re still discussing whether abort + success/failure should have a separate code or have the same one as a normal success/failure.
If we go with the same codes (1 and 2) then we won’t be able to filter these as “aborted” builds, the builds will look exactly like any other success or failed build.
If we go with new codes then quite a few things have to be adjusted, and not sure if this is actually required (whether we want to filter for these) at all. If not then this would be useless added complexity.
Don’t worry, this is still on our list for the near future, but if you have any feedback feel free to share it!
The mono repo support is also a solution to this same issue. I’m looking forward to optimizing build scheduling once that’s possible.
1 Like
@bootstraponline got it - we’ll discuss about both this week and try to decide which one is the right solution long term (or both, if we find some use case for both)
Cool. Also I ran into an edge case with required status checks and mono repo support. If there’s a required status check and no build is scheduled (due to no changed code), then the PR can’t be merged. There should be an option to report back success to GitHub when builds are skipped. Otherwise it’s not possible to have required status checks.
1 Like