gofr-dev
Updated workflow to show error on failing test
Title:
Fix: Ensure pipeline fails on failing example tests (#2408)
Description:
This PR fixes issue #2408, where the CI pipeline did not fail when tests in the examples/ folder failed.
Previously, the test step used the nick-fields/retry@v3 action without strict failure handling, allowing the workflow to pass even when tests failed after all retries.
Changes made:
-
Updated the “Test with Retry Logic” step in
.github/workflows/test.yml:- Added
retry_on: errorto ensure retries only occur on real failures. - Added
set -einside the command block so the job stops immediately on test failure. - Verified that the pipeline fails properly after two unsuccessful retries.
- Added
-
Confirmed
go test ./examples/...exits with a non-zero status when tests fail. -
Retained coverage collection and filtering steps.
Verification steps:
- Introduced an intentional failing test in
examples/to confirm the CI job fails as expected. - Observed the pipeline correctly retry twice, then exit with a failure status.
- Removed the failing test and verified the pipeline passes successfully again.
Local testing:
go test ./examples/... -v
echo $?
# Returns 1 on failure, 0 on success
Motivation:
This fix ensures CI integrity — failed example tests now correctly fail the pipeline, preventing false-positive builds.
Additional Notes:
- No new dependencies added.
Checklist
- [x] Verified example tests now fail the pipeline correctly.
- [x] Updated workflow logic with
retry_on: errorandset -e. - [x] Code formatted and linted.
- [x] No decrease in code coverage.
- [x] Linked to issue #2408.
@coolwednesday @Umang01-hash can you please review this .
@Umang01-hash @coolwednesday any updates..
@coolwednesday @Umang01-hash the example tests are failing now successfully as per the issue mentioned..
@HarK-github Thanks for the contribution — the functionality looks promising! However, the PR is currently failing due to a test error, and we’ll need to get that resolved before merging to avoid breaking the pipelines.
Would you be open to taking a look at the failing test and updating the PR? Happy to help if you need any guidance along the way.
Hi @HarK-github, we have re-run the pipeline, and it failed for two prior versions of go. You can go through and check whats the exact issue and fix it, we can discuss on the same if you face any issue.
@aryanmehrotra Hey .. How can i test the workflowpipeline myself ? right now I have to keep asking for it..
Rather than creating a PR directly on the gofr-repo, you can create a PR on your forked version's development that should also trigger the pipeline and you will have complete access there.
@HarK-github The added “wait-for-services” logic is not the correct or efficient solution. It should be rejected or replaced with Docker healthchecks if—and only if—service startup timing is genuinely causing flakiness.
The new waiting script introduces multiple sequential sleep loops (potentially adding 2–5 minutes to every CI run), even when all services are already healthy. GitHub Actions service containers (MySQL, Redis, Kafka) become available automatically once ports are exposed, so manual port polling is usually unnecessary.
If there are rare startup race conditions, a cleaner and faster solution is to rely on Docker healthchecks, for example:
services:
mysql:
image: mysql:8.2.0
ports:
- 2002:3306
env:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: test
options: >-
--health-cmd='mysqladmin ping -h localhost -ppassword --silent'
--health-interval=5s
--health-timeout=5s
--health-retries=10
--health-start-period=5s
This allows GitHub Actions to automatically wait until the container is healthy before running tests—without manual sleeps or custom loops.
Also as requested above why we have these changes ?? please revert all of them back.
@HarK-github I re-ran the workflow and the examples test are failing for all go versions. Please have a look and resolve it.
@Umang01-hash I have tried changing the workflow and still there are two failing tests. As attached in the picture, the current workflow pipeline is passing these failures without exiting with error. Example Unit Testing (v1.25) has no issues. Also @coolwednesday said the current tests are failing, so I guess my workflow is correct, the unit tests are wrong. @aryanmehrotra Could you help me with this..
Hey There !
If you are unable to connect to kafka, the workflow needs to handle the configs for the tests properly. Maybe kafka might be running at some other port. I noticed the conversation thread talked about changing ports. If something like that was done. I think that can be the main cause.
@HarK-github if that's the only solution you can go ahead and try changing port for Kafka or any other test failing with a valid reason on PR descritption, just wanted to be careful, we should only try and fix the failing tests using minimal changes in workflow.
@HarK-github are you still working on the PR?? The examples test are failing right now in the PR and as discussed if they can be fixed by changing port of the needed datasource like kafka we can try that.
@HarK-github If i can help in completing this PR i would love to do that. Since it is a good to merge thing we are just trying to get it done early. If you need any assistance please let me know. Let's try to close it soon.
@Umang01-hash I tried above methods but still no luck :/ . I don't think ports are the issue.. Do you have any ideas?..