Adding local dev script for running backend & frontend locally

[YarivHashaiComet]

Adding script to run opik in development mode.
Running docker containers
Build and running backend locally
Build and running frontend locally

./scripts/dev-local.sh

[github-actions]

Python Backend Tests Results

37 tests   35 ✅  2m 33s ⏱️
 1 suites   2 💤
 1 files     0 ❌

Results for commit ab4d3ba.

♻️ This comment has been updated with latest results.

[github-actions]

Backend Tests Results

  187 files  ±0    187 suites  ±0   20m 52s ⏱️ -53s
4 374 tests +3  4 370 ✅ +2  3 💤 ±0  1 ❌ +1 
4 370 runs   - 1  4 366 ✅  - 2  3 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit ab4d3ba. ± Comparison against base commit 86fd6a2.

This pull request removes 1 and adds 4 tests. Note that renamed tests count towards both.

com.comet.opik.api.resources.v1.priv.DatasetsResourceTest$UpdateDataset ‑ updateDataset

com.comet.opik.api.resources.v1.priv.DatasetsResourceTest$UpdateDataset ‑ updateDataset(DatasetUpdate)[1]
com.comet.opik.api.resources.v1.priv.DatasetsResourceTest$UpdateDataset ‑ updateDataset(DatasetUpdate)[2]
com.comet.opik.api.resources.v1.priv.DatasetsResourceTest$UpdateDataset ‑ updateDataset(DatasetUpdate)[3]
com.comet.opik.api.resources.v1.priv.PromptResourceTest$UpdatePrompt ‑ when__promptUpdateIsValid__thenReturnSuccess(Function)[5]

♻️ This comment has been updated with latest results.

[andrescrz]

I'll give a deeper review in a few minutes, but we shouldn't move forward with this like it is as it has fundamental problems in the approach and can cause maintainability issues.

However, the general idea is positive, so in that deeper release I'll give you indications and the context to accomplish this in the right direction.

We also scoped one backlog story with more information on how to accomplish this. I'll find the link and provide it to you.

[andrescrz]

I give better guidelines to accomplish what you want to achieve here. See OPIK-1095 in our backlog for further details on the docker groups approach.

[andrescrz]

For all these permissions changes, you should just add execution permissions for the user and leave the others like they are. This should be good for local users and for development, without impacting enterprise customers. If you take a look at Dockerfiles, generally we just run +ux or even 700. Let's prevent security reports here.

[andrescrz]

This file has a lot of overlap with the CONTRIBUTING.md one. You should consolidate and also get input from product team about how to structure it. This is important for discoverability from external contributors and the community.

This is not a strong blocker on my end, but there's been some historical context about how we structure our .md files. Although being honest, we haven't been completely strict about this and indeed there's some existing overlap and duplication already.

[YarivHashaiComet]

removing this file

[andrescrz]

Same about this file, lots of overlap with the new QUICKSTART.md in this PR and also with the pre-existing .md files.

[andrescrz]

This file has a lot of overlap with the existing opik.sh etc. files. Diverging from them creates multiple issues:

• Windows users and contributors is not supported, but it should, like opik.ps1 files.
• Community won't know exactly if using the existing scripts or this one.
• Increases maintainability, as we need to support both (and also windows flavours).

In general, this should be accomplished with docker groups instead. If you tweak the docker-compose file to add groups (opik, be, fe, infra etc.) you'd just need to update the opik.sh and opik.ps1 files to pass flags on the ones to activate, without further changes.

See OPIK-1095 in our backlog for further details.