I'll try and help out tonight.

would it be possible to link to the failure? with a starting point, I can at least see if I can re-create

I also just started looking into this

here: https://app.circleci.com/pipelines/github/BetterThanTomorrow/calva/7043/workflows/2fe02f9f-24db-4708-9ea2-73748a6421a4/jobs/35778

The first few errors seems to happen because vscode can't talk to dbus... this makes sense as there's no dbus daemon in the image (`cimg/clojure:1.11-browsers`) and there doesn't seem to be any provision to connect to a bus outside of docker. Unclear whether it's just the latest vscode that requires this dbus connection or whether there was some previous workaround that doesn't work anymore

Actually dbus doesn't seem relevant, a https://app.circleci.com/pipelines/github/BetterThanTomorrow/calva/7038/workflows/f963016e-3a5e-45b4-8e60-975842f318f3/jobs/35728 also has the same errors

Thanks for having a look, @U74MQ2347! Indeed, the dbus error is always there. 😃

@U013JFLRFS8 see the link that @U74MQ2347 pasted.

Anyone: You can probably see a successful run if you build Calva locally and run the integration tests, • Building Calva locally: With the Calva repo open in VS Code, Run Build Task (`ctrl/cmd+alt+b`) • Run integration tests: npm run integration-test

possibly related, seems like the same error and this report of recurrence is from 4 days ago, so the timing seems to line up pretty decently: <https://github.com/microsoft/vscode/issues/188676#issuecomment-1725627276>

although I don't totally get why a local run succeeds if this is related

I couldn't get the integration test to run locally (build pipeline works nicely, it's just that nixos requires specially built vscode binaries :face_with_rolling_eyes: ) so I wrote a https://github.com/simonacca/calva/blob/build-in-docker/Dockerfile that does just enough to build run the integration tests with the same images that circleCI uses. There the tests fail (in a very similar manner as it does in circleCI) on ~50% of the runs. • build with DOCKER_BUILDKIT=1 docker build --tag calva-ci-integration --target test-integration . • run with docker run -ti --net host -e DISPLAY=:0 --rm --ipc=host calva-ci-integration

That’s great, @U74MQ2347! Can you file a PR with that Dockerfile and the instructions? Maybe in the scripts folder, scripts/build-and-test, say.

That looks very related, @U013JFLRFS8. Maybe a temporary fix is to use the regular Code, instead of Insiders…

it might be worth at least trying w/ regular once to isolate that variable I don't want to pretend I'm some devops expert, but I wonder if it's worth thinking about tweaking the strategy of the integration tests. I think using the insiders version definitely has the value prop of catching issues before they pop up in stable, but the trade-off there feels like if an issue does pop up, it's not necessarily clear if it's in the calva code or the 'integration API' (vscode). I'll throw out two ideas, just spitballing: • CI builds run integration tests against both stable and insiders - idk if there's a way to fork the workflow, or maybe just run against stable, and if that passes, run against insiders so there's always a point of comparison • CI builds run against stable, and a scheduled build (if that's possible to setup) runs dev against insiders - my thinking behind this is that a) there's still sort of a point of comparison, and b) changes to the insiders build might happen at a different pace, so if e.g dev hasn't changed but the integration tests with insiders start failing, that's likely a signal that something has changed at the integration boundary (rather than a change to calva 'breaking')

just as a really left-field thought, if calva were to do a scheduled build, it might even be possible to use nightlies of vscode (assuming they publish nightlies), and then, for example, if that issue report is fixed on nightly but not yet on the insider build, this current issue might have popped up and then gone away

Here’s an issue where we can collect clues and discuss: https://github.com/BetterThanTomorrow/calva/issues/2317

I think the idea about using both stable and Insiders has merits. The drawback is that the pipeline is complicated enough as it is. I’m not sure what to do with the canary signal if it isn’t allowed to break the build like it does today. Over four years and 400 Calva versions this is the first time we’ve run into troubles with using Insiders only. Maybe just having a fallback prepared to easily switch to stable to get out some urgent upgrade of Calva is fine.

@U0ETXRFEW https://github.com/BetterThanTomorrow/calva/pull/2320's the PR. While cleaning it up this morning I re-run the integration tests and now everything passes 100% of the time... maybe this is the case on circleCI as well now?

Your PR failed at CI, so there’s that. 😃 Thanks a ton for this help! 🙏 (The failure is the integration test we are talking about so has nothing to do with your PR, in case that wasn’t clear.) I have seen one build pass CI the latest days. So it seems it is flaky also there.

The desired result is MITRA_MOCK=false

Does just "MITRA_MOCK": false, work?

It seems not to be working.. I am running unit tests and there is a part that should only be run when the mock is false, and it is not entering the tests

Hmmm, if I have this config:

"calva.jackInEnv": {
    "IS_FOO": true
  },

(System/getenv "IS_FOO") => "true"

Actually the System/getenv returns "true", so it doesn't change it at all..

Can it have to do with the way I'm connecting to REPL? I'm running a docker container and using the generic type with the container port to do the jack in

Can you describe in a bit more detail how you connect? Sounds like maybe you are not using a jack-in command? But, yes, the environment will only update for the process starting the repl, and I don’t see how it would automatically be picked up inside a docker container.

So first I start the docker container with REPL like this and then I choose "Connect to a running REPL" - > Generic - > Port 32000 P. S. And yes, I just saw that I'm not using the jack in 😂 do you know if there's a way to still pass the env variable with this setup? :thinking_face:

To get an env variable in there you’ll need to start the process with that variable set. One way to do it is to use https://calva.io/connect-sequences/#custom-command-line that starts the docker container and add the environment variable there. (Or start the container like you do today, adding the environment variable to it, would work too.)

(Jack-in is not a good name, btw, but we’re sort of stuck with it… 😃 )

Thanks so much for your help, somehow I got it to work changing the docker command line command overriding just one env variable, tried to do it with custom connect sequence, but somehow the container stops by itself after a minute 😅 anyway, happy that it's working haha

Great that you got something that works! I’m a bit curious about why the container doesn’t survive when started via jack-in, though. Did you get any error messages when it died??

I don’t think you can. The connect sequence ends when the cljs repl is connected and will leave things there. You might get away using the runCommands command and stringing the jack-in and toggle connection commands together, but I’m not sure the promise chain is unbroken all the way to support that.