Include .git directory in the Docker image

[ahangarha]

We need to have the .git directory in the deployed project to get and show the commit hash of the deployed project.

---

This change is 

[justin808]

This is incorrect AFAIK. @borela how do you get the commit better in docker builds?

[justin808]

see prior comment

[borela]

You can use ARGs and pass the commit to the build command.

[ahangarha]

You can use ARGs and pass the commit to the build command.

But we use cpl to build images to deploy on ControlPlane.
We need another mechanism to do this.

I am thinking of a rake task for this. It can return the value from either an env variable like GIT_COMMIT, the result from git command (if available), or a custom text for an unavailable commit hash.

This way, the code works fine regardless of being in docker or not.

Note: cpl supports this implementation:

cpl -h build-image
Usage:
  cpl build-image -a, --app=APP_NAME

Options:
  -a, --app=APP_NAME               # Application name
  -c, [--commit=COMMIT_HASH]       # Commit hash
  -d, [--verbose], [--no-verbose]  # Shows detailed logs

Description:
  - Builds and pushes the image to Control Plane
  - Automatically assigns image numbers, e.g., `app:1`, `app:2`, etc.
  - Uses `.controlplane/Dockerfile` or a different Dockerfile specified through `dockerfile` in the `.controlplane/controlplane.yml` file
  - If a commit is provided through `--commit` or `-c`, it will be set as the runtime env var `GIT_COMMIT`

[borela]

@ahangarha we need to update the tool to be able to pass args to the docker image too, people might need it for other purposes.

[ahangarha]

@borela Got it.
So this is a good example to test the feature.
Should I open a new issue on CPL project?

[justin808]

See shakacode/control-plane-flow#117

[justin808]

See #117

[justin808]

Why?
Ask ChatGPT

why should the .git directory be included in a .dockerignore
ChatGPT
Including the .git directory in a .dockerignore file is a recommended practice for several reasons:

Reduce Image Size: .git directories often contain a lot of metadata and historical data that are not necessary for running the application. Excluding this directory can significantly reduce the size of the Docker image.

Security: The .git directory may contain sensitive information, such as commit history, configuration details, or even credentials in some cases. Excluding it from the Docker image helps to prevent unintended exposure of this information.

Build Efficiency: Docker builds can be faster when the context sent to the Docker daemon is smaller. The .git directory can be quite large, especially for long-standing projects, so excluding it can speed up the build process.

Clean Environment: Docker images are intended to be minimal and specific to the application's runtime requirements. Including only what is necessary for the application to run ensures a clean, minimal environment, which is a best practice for Docker usage.

Avoid Unnecessary Rebuilds: Docker uses the context sent to the daemon to determine if an image needs to be rebuilt. Changes in the .git directory that are irrelevant to the application's functionality could trigger unnecessary rebuilds, thus excluding it can help in avoiding this.

Compliance and Best Practices: For compliance with various security and operational best practices, it's essential to keep Docker images lean and free from unnecessary files. This aids in maintaining a standardized and secure deployment process.

In summary, excluding the .git directory from Docker builds results in smaller, more secure, and efficient images, aligning with best practices for Docker usage.