-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(app): detailed status messages #1289
Conversation
@ciyer @andre-code You can test against the CI deployment. Let me know what you think. |
This is a draft because I want to make sure any changes from the ui side are addressed before someone reviews. |
You can access the deployment of this PR at https://renku-ci-nb-1289.dev.renku.ch |
Thanks for this implementation @olevski , it works very well 👏, here you can find the UI implementation using this new information. |
5540da0
to
d45dd43
Compare
d45dd43
to
1c0d936
Compare
1c0d936
to
6b2a7c2
Compare
6b2a7c2
to
169ea7e
Compare
169ea7e
to
a9515a5
Compare
a9515a5
to
d56a41d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
closes #1135
Provides more detailed information about server status.
Example status section of server response:
Possible step states:
Because of how containers react in k8s I modified the terminology a little bit. A container can be ready if it completes with 0 exit code or if it run and it passes all its probes. When all containers (i.e. steps) are ready then the whole session is ready. But the definitive flag on when the session can be accessed and is 100% ready is the
status.state
value. Thestatus.state
value will even check if the URL is reachable before turning to "running"./deploy #persist