-
Notifications
You must be signed in to change notification settings - Fork 7
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
mcobbett exit immediately when all tests done #298
mcobbett exit immediately when all tests done #298
Conversation
Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
…ult was being copied over into the reported structure. Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
Build failed, see http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/#/namespaces/galasa-build/pipelineruns/repo-cli-pr-298-x7c6n for details. If you are unable to do so, please contact a member of the Galasa team. |
Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
Build failed, see http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/#/namespaces/galasa-build/pipelineruns/repo-cli-pr-298-89bs2 for details. If you are unable to do so, please contact a member of the Galasa team. |
Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
Build failed, see http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/#/namespaces/galasa-build/pipelineruns/repo-cli-pr-298-gbl7m for details. If you are unable to do so, please contact a member of the Galasa team. |
Build successful |
1 similar comment
Build successful |
Signed-off-by: Mike Cobbett <77053+techcobweb@users.noreply.github.com>
Build successful |
Why ?
While investigating galasa-dev/projectmanagement#2009 I noted that the CLI tool didn't exit the moment the last test completed.
It used to but at some point it stopped doing that.
It turns out that 2 timer services were being created. One thread went to sleep on one, and the other thread woke up on the other. So the interrupt event never woke the sleeping thread.
Solution: Use a single sleep service, and separate the sleeper service from the time service so it's less likely in the future.
Also, using the golang select... and time.After(delay) is the recommended way of doing this stuff as of Golang 1.23. What I've coded does work, but prior to 1.23 may result in a timer resource leakage.
We need to uplift the golang requirement to 1.23 next to avoid any resource leakage.