Comments (11)
Yes, it fails only sometimes.
To debug this, I added another tmate session step that will be available only in case of failure.
I also increase the frequency of the cron so that failure should happen more frequently.
If I'm here during a failed test, I will debug with tmate and try some ddev logs
or whatever.
[EDIT]: damned, I was able to enter in a failed workflow : https://github.com/ddev/ddev-mongo/actions/runs/5873818472/job/15927617320 but, as the bats teardown is deleting all the project (ddev delete -Oy ${PROJNAME} >/dev/null 2>&1
), I was not able to run some ddev logs
command in the project.
Do you have any idea of what we should looking as the project and files have been removed by the teardown method ?
Maybe I can just create a test-ci.bats
that will not remove anything in the teardown if we detect a failed test. (not sure how to do that...)
from ddev-mongo.
Solved by 6651175
from ddev-mongo.
Hi @rfay ,
I'm surprised that I didn't receive any alert from GitHub for this failed job: I subscribed for "all activities" notification, so I expected to be notified. Maybe there is another setting somewhere.
I compared some other add-on tests and I saw that we are using here ddev restart >/dev/null 2>&1
for the directory test.
For all other add-on I looked at, this is ddev restart >/dev/null
(or even just ddev restart
).
I guess this is probably not the root cause but I modified into ddev restart >/dev/null
, and I'll keep an eye out.
Maybe we could add temporary some verbosity to debug by adding a secret ACTIONS_STEP_DEBUG
(true
) like explained here: https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging (only the owner can do that if I understand correctly)
from ddev-mongo.
I'm surprised that I didn't receive any alert from GitHub for this failed job: I subscribed for "all activities" notification, so I expected to be notified. Maybe there is another setting somewhere.
I've had this problem with repositories as well, and haven't sorted it out. Repos created? by someone else don't send me their failures. I guess maybe it's something we could open an issue about. Certainly baffles me.
You can debug this on Github hardware by going to https://github.com/ddev/ddev-mongo/actions/workflows/tests.yml and clicking the button in the upper right "Run Workflow" and check "Debug with tmate". It will let you ssh into the machine and see what actually happens. I guess there's inadequate docs on that approach.
![image](https://private-user-images.githubusercontent.com/112444/260713235-8f8fa3fc-3afd-43e6-ab13-917db636d7d2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTg4NjMzMDYsIm5iZiI6MTcxODg2MzAwNiwicGF0aCI6Ii8xMTI0NDQvMjYwNzEzMjM1LThmOGZhM2ZjLTNhZmQtNDNlNi1hYjEzLTkxN2RiNjM2ZDdkMi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNjIwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDYyMFQwNTU2NDZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02NDk2MDcwOGQ0YTdmOWU3MzcxNWFiNGYxZDZlZDIzZDY0YTI4ZTc3YzRjMzZmMDFiMGJkYjcxOGE0MmE1NjQxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.DFS5cNRYggGSkewA3XuQMe6gvSvPZBwDbiOrRY3rEcg)
from ddev-mongo.
However, as we see, the test ran OK for you and the nightly worked last night :( I guess we just need more output from the test to understand what's happened.
from ddev-mongo.
Just remove the teardown for now I'd say. It properly tears everything down at the start, so it doesn't do any harm. Thanks for chasing this!
from ddev-mongo.
Removing the teardown gives some progress but, as the following test (install from release) is run after a failed one, some content are wiped and we are loosing information.
By the way, I saw the original error was (https://github.com/ddev/ddev-mongo/actions/runs/5875221214/job/15931158670#step:11:14) :
Could not check for updates. This is most often caused by a networking issue.
# ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys.
# Failed to restart testmongo: container(s) failed to become healthy before their configured timeout or in 120 seconds. This may be just a problem with the healthcheck and not a functional problem. (container 'mongo-express' exited, please use 'ddev logs -s mongo-express' to find out why it failed)
And when I went in the tmate session I ran ddev logs -s mongo-express
and it returns:
Waiting for mongo:27017...
/docker-entrypoint.sh: connect: Connection refused
/docker-entrypoint.sh: line 14: /dev/tcp/mongo/27017: Connection refused
Wed Aug 16 06:07:52 UTC 2023 retrying to connect to mongo:27017 (2/5)
Welcome to mongo-express
But this is maybe the log after the second test...
Finally, I created a specific debug action with only the "install from directory" test and will run it manually to see if I can understand more.
from ddev-mongo.
With the new specific debug action,
we can see that failed is coming from mongo-express that tried 5 times to connect without success:
(result of ddev logs -s mongo-express --tail 500
below)
Waiting for mongo:27017... /docker-entrypoint.sh: connect: Connection refused /docker-entrypoint.sh: line 14: /dev/tcp/mongo/27017: Connection refused Wed Aug 16 06:23:40 UTC 2023 retrying to connect to mongo:27017 (2/5) /docker-entrypoin
t.sh: connect: Connection refused /docker-entrypoint.sh: line 14: /dev/tcp/mongo/27017: Connection refused Wed Aug 16 06:23:41 UTC 2023 retrying to connect to mongo:27017 (3/5) /docker-entrypoint.sh: connect: Connection refused /docker-en
trypoint.sh: line 14: /dev/tcp/mongo/27017: Connection refused Wed Aug 16 06:23:42 UTC 2023 retrying to connect to mongo:27017 (4/5) /docker-entrypoint.sh: connect: Connection refused /docker-entrypoint.sh: line 14: /dev/tcp/mongo/27017:
Connection refused Wed Aug 16 06:23:43 UTC 2023 retrying to connect to mongo:27017 (5/5) /docker-entrypoint.sh: connect: Connection refused /docker-entrypoint.sh: line 14: /dev/tcp/mongo/27017: Connection refused Welcome to mongo-express
------------------------ Mongo Express server listening at http://0.0.0.0:8081 ESC[31mServer is open to allow connections from anyone (0.0.0.0)ESC[39m ESC[31mbasicAuth credentials are "admin:pass", it is recommended you change this in you
r config.js!ESC[39m /node_modules/mongodb/lib/server.js:265 process.nextTick(function() { throw err; }) ^ Error [MongoError]: failed to connect to server [mongo:27017] on first connect at Pool.<anonymous> (/node_modules/mongodb-core/lib/t
opologies/server.js:326:35) at Pool.emit (events.js:314:20) at Connection.<anonymous> (/node_modules/mongodb-core/lib/connection/pool.js:270:12) at Object.onceWrapper (events.js:421:26) at Connection.emit (events.js:314:20) at Socket.<ano
nymous> (/node_modules/mongodb-core/lib/connection/connection.js:175:49) at Object.onceWrapper (events.js:421:26) at Socket.emit (events.js:314:20) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams
/destroy.js:60:3)
No idea why but this is a beginning.
from ddev-mongo.
Maybe related: mongo-express/mongo-express-docker#39
from ddev-mongo.
Hi @rfay ,
it seems that adding entrypoint: [sh, -c, "sleep 5s && tini -- /docker-entrypoint.sh mongo-express"]
as a workaround make it work (found in the above related issue).
Will let test running for some days to see if it is ok.
It seems that for some reason, mongo-express
sometimes tries to connect when the mongo
container isn't ready.
This is why the solution is to add 5 seconds before trying to connect.
from ddev-mongo.
Wow, nice work.
I'll bet that it has to do with healthcheck. ddev-mongo has one,
ddev-mongo/docker-compose.mongo.yaml
Lines 28 to 30 in 57fe742
But mongo-express has a depends-on
which should actually do the job, it should wait for mongo. There are periodic problems in docker-compose with depends-on and there have been some things going on there lately, https://github.com/docker/compose/releases
I guess a wait in start is not the biggest problem for a gui element here. Congrats on the great work on this.
from ddev-mongo.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ddev-mongo.