Added Dev Container configuration to simplify local setup

[barakiva]

Struggling to get the project to work on my system which lacks various dependencies like PHP 8.2 or Ant, I've decided to go ahead and try dev-containers (asdf was too much of a pain) and after much tinkering was pleased with the result.

I've created a devcontainer.json that enables you to spin up a container and develop there. All PHP dependencies including XDEBUG are set up in a Dockerfile that is being read by devcontainer.json.

I've also added postInstall commands like:

• composer install
• cp config.dist.php config.php
• some LDAP setup so composer test doesn't complain

In conclusion i've tried to boil down everything you have to manually do before you can run testing. I'm also thinking about a way to easily populate the config.php from the command line, or even do the install from the terminal so people new to the project (like myself) wouldn't have to struggle so much.

BTW this is my first ever PR. New to contributing to open source so please any feedback is welcome.

[JohnVillalovos]

Docker related changes are done in the https://github.com/LibreBooking/docker Please propose it there.

[JohnVillalovos]

@barakiva Thanks for the submission though!

[barakiva]

@JohnVillalovos Hey John thanks for the reply!

I think the docker repo is intended for running the app? The PR was made with the intention of streamlining source code development, not necessarily hosting.

But i can understand if development tooling does not fit the scope of the project.

[JohnVillalovos]

@barakiva Okay. I'll reopen and see if @colisee has input on this. I just worry that people will try to use the Dockerfile in this change to try to run LibreBooking in a container.

Not saying will merge this, but will re-open to see if we get feedback from others.

[barakiva]

@barakiva Okay. I'll reopen and see if @colisee has input on this. I just worry that people will try to use the Dockerfile in this change to try to run LibreBooking in a container.

Not saying will merge this, but will re-open to see if we get feedback from others.

Thank you very much for re-considering! If you worry people will get confused with two Dockerfiles, I think I could prevent this problem from happening. I guess I could add documentation (was planning to anyways if this got merged), and add scripts to composer.json. Something like start:dev or start:prod that each call their respective Dockerfiles.

[colisee]

Hi @barakiva, could you please tell us what the difference is between your proposal and the Librebooking docker repository ?

FYI, I am working on issue-124 (in the docker repository) that will allow the container to be run by a non-root user (in this case www-data).

[colisee]

@barakiva , my understanding is that devContainer offer a consistent development environment to all developers, based on a specific project (for instance librebooking), while docker/podman focus on running an application, regardless of the dependencies available on the host. Am I Right?

If yes, then I would presume that your PR makes real sense inside the librebooking/app repository and would greatly enhance the efficiency of the developers, for they would no longer need to install project-related dependencies on their system.

[barakiva]

@barakiva , my understanding is that devContainer offer a consistent development environment to all developers, based on a specific project (for instance librebooking), while docker/podman focus on running an application, regardless of the dependencies available on the host. Am I Right?

If yes, then I would presume that your PR makes real sense inside the librebooking/app repository and would greatly enhance the efficiency of the developers, for they would no longer need to install project-related dependencies on their system.

Exactly! Couldn't have written it better myself.

It's very hard to get the environment right for PHP development as unlike the Javascript and Python ecosystems (with which I have the greatest experience) dependencies are not contained within the project but "spread out" across the system, making it hard to support more than 1 project at once.

It's especially annoying when working from your laptop and you have to remember all the magic incantations required to get tests, linting etc to run. Dev containers is a great feature that enables developers to standarize development in an idempotent, repeatable immutable manner.

[colisee]

To @JohnVillalovos and @lucs7

Further to this discussion, I believe that devcontainer is an interesting feature for developers who need a consistent environment to work on the project. As such, the PR should logically take place inside the librebooking/app repository.

I would recommend the reading of this article and creating a new markdown document that clearly explains how to use devcontainer for developing activities.

[barakiva]

To @JohnVillalovos and @lucs7

Further to this discussion, I believe that devcontainer is an interesting feature for developers who need a consistent environment to work on the project. As such, the PR should logically take place inside the librebooking/app repository.

I would recommend the reading of this article and creating a new markdown document that clearly explains how to use devcontainer for developing activities.

I will get working on the document. Should I write as if I assume the reader is using dev containers with vscode?

[lucs7]

Dear @barakiva,
I like the idea of the dev container, but I do not see how the commit works.
What is the ldap_setup.sh supposed to do ?
Where is the database to run the devcontainer?
Why don't we use the existing container with watch?

[lucs7]

I created a possible option for a dev container based on the existing docker image. unfortunately I have to use a permission rewrite which might be solved with the idea to move the container execution to a non-root user

lucs7@03d4f43
@barakiva can you test it?

[barakiva]

I created a possible option for a dev container based on the existing docker image. unfortunately I have to use a permission rewrite which might be solved with the idea to move the container execution to a non-root user

lucs7@03d4f43 @barakiva can you test it?

Hey I will check this.

The ldap_setup was poorly named. I've already written something else but didn't push the changes. Will get up on it today.