openmcp-project / openmcp-project/docs
Development environment setup needs some love
Nobody has claimed this yet.
- Dominant language
- CSS
- Stars
- 1
- Forks
- 7
- Avg merge
- 8d 9h
- Merged PRs (30d)
- 10
Description
So, the e2e test in the template is actually doing a fantastic job in providing an environment in which to test the controller.
But, as a service provider dev, I would love a simple approach to bootstrap an environment. And I saw that https://openmcp-project.github.io/docs/operators/boostrapping exists, but that's hilariously long. :D
My suggestion would be to go the CAPI/CAPA route here. I believe it would improve the development life-cycle by a huge margin.
Cluster API (CAPI) is using a set of Tiltfiles Tilt to bootstrap a cluster environment. And then the providers just have a tilt-provider json file that describes there deployment needs. So the user clones capi and capa and then just runst tilt-up and things just work magically from there. And delve can be used for debugging and no e2e-test-breakpoint-attach-run-stuff is needed from there to bootstrap an entire environment.
Now, I know investing in this requires some fingerspitzengefühl, but honestly, the sooner the dev environment setup is cozy and a one-liner the better. Because it seriously impacts the speed at which people can write an operator and test its functionality.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the e2e test in the template and the existing docs/operators/boostrapping guide to understand the current setup. Compare the referenced Cluster API Tiltfile, tilt-provider.json, and tilt-up flow. Done would mean a documented, simple development-environment bootstrap approach with the proposed debugging workflow, but the issue does not identify implementation files or tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- developer-experience, devops, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100