Adding exception field on release api#1
Merged
Cryptophobia merged 7 commits intomasterfrom Nov 13, 2017
Merged
Conversation
Member
Author
|
This PR is related to this upstream PR: |
tmedford
approved these changes
Nov 13, 2017
kingdonb
pushed a commit
to kingdonb/controller
that referenced
this pull request
Aug 6, 2019
Refactoring for new KubeHTTPClient.version() behavior
kingdonb
pushed a commit
to kingdonb/controller
that referenced
this pull request
Aug 6, 2019
Refactoring for new KubeHTTPClient.version() behavior
duanhongyi
added a commit
to duanhongyi/controller
that referenced
this pull request
Jan 3, 2021
…o-1.11.21 chore(deps): bump django from 1.11.20 to 1.11.21 in /rootfs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We noticed that the api was giving great exceptions when you make a request that fails, but we would like to store those detailed exceptions up to the release api object for version of the release on which they occurred. Similar to how
failed=Trueis available on the release api object, there should be a field calledexceptioncontaining the exception msg from the deis-controller when a release or build fails.Let's say we make a
/scalepost request toPOST http://deis.192.168.99.100.nip.io/v2/apps/testing-application/scalewith the following payload:With this PR, when a release fails this is the example of how the release api response will look:
GET http://deis.192.168.99.100.nip.io/v2/apps/testing-application/releasesWith this small change we get a detailed message in the api telling us why a certain release failed that is more detailed than the summary message. As a benefit it is stored on the release API object rather than just given as a response to our API calls: