fetch secrets from <workspace>/.continue/.env folder before <workspace>/.env

[uinstinct]

Description

Fetch secrets from /.continue/.env file before fetching from workspace .env

So now the order of fetching the first env file is ~/.continue/.env, <workspace>/.continue/.env, <workspace>/.env

https://discord.com/channels/1108621136150929458/1355378099004379248/1367363239792476211

Checklist

• [] I've read the contributing guide
• [] The relevant docs, if any, have been updated or created
• [] The relevant tests, if any, have been updated or created

Screenshots

[ For visual changes, include screenshots. Screen recordings are particularly helpful, and appreciated! ]

Testing instructions

1. Create a .env file inside the .continue directory
2. Add key value pairs
3. Use the secrets in config yaml
4. See them reflected via config

[netlify]

✅ Deploy Preview for continuedev canceled.

Name	Link
🔨 Latest commit	610814e
🔍 Latest deploy log	https://app.netlify.com/projects/continuedev/deploys/683af26e5440b20008ef6355

[tomasz-stefaniak]

@uinstinct could you add tests for this as documentation and to prevent future regressions?

[uinstinct]

hey @tomasz-stefaniak

there is some problem when am trying to mock a local file as jest is unable to resolve it. it seems like a problem with how jest is setup. I tried various ways to get it working. Currently none of these work.

Any idea what should I do to a mock?

(I need to mock utils/paths for imported functions like getContinueDotEnv())

[tomasz-stefaniak]

@uinstinct have you checked some existing instances of jest.mock we have in the codebase?

I understand most of them are for node packages but maybe they can point you in the right direction. If you are still stuck, let me know and I can try to pull this into the sprint next week.

[uinstinct]

Thanks for replying Tomasz!
I had tried these actually but for some reason jest is unable to resolve it.

For alternative options, we can:

1. use the filesystem env (problem: the test might affect the local users .env)
2. use a conditional (process.env.TEST flag) inside getContinueDotEnv to produce a key value pair for testing

[uinstinct]

Spent some more time debugging this. Looks like the module resolution was starting from core/test folder since jest was declared as global in core/test/jest.setup-after-env.js

So, ../util/paths would work but not ../../util/paths.

[uinstinct]

Okay. Tried both unstable_mockModule and jest.mock('../util/paths') both which resolve correctly but do not mock implementations for some reason.

[tomasz-stefaniak]

Update: this is a huge pain, I'm exploring migrating to Vitest 😆

[uinstinct]

🥲 Agree!!!
BTW, can i help in some way? I have some experience with migrating jest to vitest.

[tomasz-stefaniak]

That would be great, actually! Do you think you'd be able to create a basic vitest setup? It could be on this branch, and it would be used to run LocalPlatformClient.test.ts. Once this proof of concept works we can migrate other tests to vitest.

This would also require adding an extra step here: https://github.com/continuedev/continue/blob/main/.github/workflows/pr_checks.yaml

Let me know what you think!

[uinstinct]

implemented!

• vitest works nicely (and with mocks) 🥳
• added vitest running for LocalPlatformClient only in pr_check.yaml

Edit: Should I draft another PR to migrate core tests to vitest?

[tomasz-stefaniak]

Edit: Should I draft another PR to migrate core tests to vitest?

Yeah, that would be great. It's one of our more important tasks at the moment.

[tomasz-stefaniak]

Thanks! Great job and thanks for introducing vitest.

Edit: Should I draft another PR to migrate core tests to vitest?

I'd love that, it's very high on our priority list.