You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in #126, this charm's CI has been showing as working (eg: ✔️ ) even though the workload is not deploying properly. This led to us at some point in the past breaking the charm without noticing, and then catching it when it blocked a few unrelated efforts.
We should fix this CI, as well as any root causes for why it doesn't work (likely we need to address #82 as well, because sometimes the workload is up but not healthy).
In order to test the health check described in #82 (comment), implement the following logic:
misconfigure the workload in order for the service to not replying successfully and the workload health check to be failing
Then either:
i. Wait 40 seconds which are the seconds that the health needs to be set to down (threshold * (period + timeout)). Then, fire an update-status in order to verify that the charm's status will reflect the workload's status
ii. Configure model to fire update-status every 10 seconds using fast-forward and assert that the charm status is maintenace with a proper timeout. This can be done either like this or this.
Bug Description
As described in #126, this charm's CI has been showing as working (eg: ✔️ ) even though the workload is not deploying properly. This led to us at some point in the past breaking the charm without noticing, and then catching it when it blocked a few unrelated efforts.
We should fix this CI, as well as any root causes for why it doesn't work (likely we need to address #82 as well, because sometimes the workload is up but not healthy).
To Reproduce
See #126.
Environment
Relevant Log Output
Additional Context
No response
The text was updated successfully, but these errors were encountered: