-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add dev container with Celix dependencies #656
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #656 +/- ##
==========================================
+ Coverage 83.11% 83.47% +0.35%
==========================================
Files 254 254
Lines 32929 32979 +50
==========================================
+ Hits 27369 27528 +159
+ Misses 5560 5451 -109 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for developing in a container, but I do think that a gitpod or github codespaces setup is probably more valuable.
See also #613 and an old experimental branch for gitpod:
master...pnoltes:celix:feature/gitpod
WDYT?
@pnoltes I tried the I also tried with my suggested Containerfile to execute as a non-root user within the container, but didn't succeed. This seems to be a known 'issue' with volume mounts. Normally for operational applications for data volume mounts there is an entrypoint which When wanting to delete these files as a non-root user on the host you can do e.g. Were you able to build Celix using that gitpod container locally? |
Yes, the main issue I had was the - at the time - I could not run (and thus also not debug) gtests from the IDE. But do note that this was about 3 years ago, I am not sure how much gitpod has changed. |
For me the build already fails with the gitpod /home/rlenferink/workspace/asf/celix/celix-container/build (feature/add-dev-container) $ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_TESTING=ON ..
CMake Error: Unable to (re)create the private pkgRedirects directory:
/home/rlenferink/workspace/asf/celix/celix-container/build/CMakeFiles/pkgRedirects
gitpod /home/rlenferink/workspace/asf/celix/celix-container/build (feature/add-dev-container) $ mkdir testDir
mkdir: cannot create directory ‘testDir’: Permission denied I had the exact same issues when I tried a non-root user in the Containerfile of this pull request. This seems intended behavior to lock down the users who are able to write to volumes.
Neither am I. Every Apache committer is allowed a Jetbrains license for their OSS work, so that is what I am using and am experienced with. My goal was to play around and see if I can extend the Containerfile for use with Clion and then as follow-up see how this can be integrated in e.g. GitHub codespaces. |
I added the SSH package and configuration. I tested this with CLion 2022.x and the latest CLion version (2023.2.x), and the IDE has an option to specify a remote development environment: https://www.jetbrains.com/help/clion/2023.2/remote-development-a.html That means that instead of setting up a Remote Host and the IDE constantly copying files (even though the deployment mapping says otherwise), it downloads and starts an IDE backend within the container. The IDE on the host is connecting to that and there is no loss in speed between editing, building and testing. Since this is up to the IDE, there are no Jetbrains specific items added, which means that the container can also be used standalone (volume mount the sources, open a shell and Feedback / thoughts are welcome ;) |
Interesting, give me some time to try this out. I am especially curious how much work it is to set this up and whether you can save your setup to quickly resume. |
What's the advantage of using container over using a Vagrant box (virtual machine)? In my personal experience, containers have far more restrictions than VM, and is generally more difficult to set up correctly. Most of the issues discussed here don't exist if VMs are used, and we won't have #658. Yes, containers are more efficient than VMs, but that does not mean much except for CI. Moreover, Vagrant can work with containers. For individual developer, Vagrant can serve as a convenient CLI, whether using VMs or containers. |
I cannot yet build the image, getting the following error:
This is also why I am not sure if we should add a dev container or dev virtual machine configuration, this requires us to maintain and document the dev container image and/or virtual machine configuration. The reason why I see more value in a gitpod config or Github codespaces is that this enable users / potential developers to try out Apache Celix without setting up a machine or even needing a machine (browser based). |
For me personally it is that I am familiar with containers and am using them extensively, and am not familiar / have never used vagrant. My experience with VMs is that it is quite often just a bit slower and file-sharing between host and VM is mostly a pain point (how else do we get to use an IDE ?).
Just for reference, the command I used was
This indeed is true. Whether we offer a dev container, a VM template or something else, it needs to be maintained.
For me personally I am not extremely content with more-and-more usage of cloud-based technology for these kind of things. The main reason is that only the first 'X' amount of hours is for free and if a certain amount of hours is exceeded then there is a need to pay said providers (obviously). Since I am mostly using my personal environment for this and doing this outside of work I have no intend to pay for these services. I am definitely not against having a codespaces/gitpod image, but at least there should be an alternative so we don't force people to use these providers if they don't want to (or there should be instructions on how to use it locally). Maybe we should/could even be offering multiple developer solutions (vanilla container, codespaces container, VM template etc...) ? |
@pnoltes I just got the Gitpod image working as well, however it is a bit slow. Feel free to give it a try via my own repo: https://gitpod.io/#https://github.com/rlenferink/celix The speed of it makes me aim to also include the instructions to run it locally (which we maybe can even use the same gitpod image for) |
Nice, I see that there is now more support than only browser vscode. |
container/README.md
Outdated
|
||
```bash | ||
podman login docker.io | ||
podman push docker.io/apache/celix-dev:$(date +%Y%m%d)-gitpod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure how easy it is to automate this. I think, since the dependencies don't change that often, that initially it would be okay to push this manually.
Building this every time takes unnecessary build time IMO and also the versioning is not tightly coupled to a Celix release.
I tested the gitpod environment and from what I could see this works nicely. Few remarks:
@rlenferink WDYT? |
This allows building and developing of Celix by using this pre-built container
7aa2d70
to
21cf541
Compare
@pnoltes in my opinion, what we definitely need to deal with is support for building and running the containers. E.g. if the However, there can be a lot of different IDE related questions and failures and I would say support for that is best effort. In case we have experienced the failure ourselves than we can potentially provide an answer, but otherwise we highly depend on the contributor. We can always ask the contributor if they can propose a fix themselves for the build problem they are facing. |
I agree, could you create a issue to update the github actions so that building in a container image is also tested? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I do think a additional build task is needed to ensure that the container based build/dev keeps working, but this can be done in a separate PR.
This allows building and developing of Celix by using this pre-built container