dev.Dockerfile: use cache mounts to speed up rebuilding

[ZZiigguurraatt]

• dev.Dockerfile now uses
  cache mounts
  to cache the GOMODCACHE and GOCACHE directories so that dependencies don't
  need to be re-downloaded and re-built every time the image is re-created.
  As a result of this change, dev.Dockerfile now requires
  BuildKit to build. When using
  docker build, this can be enabled by setting the environmental variable
  DOCKER_BUILDKIT=1. BuildKit also does not unnecessarily rebuild images when
  the build context is a remote git repository because COPY layers are more
  smartly compared to cache.

Would like some feedback on this change. Not sure if it might have some unintended consequences that I have not thought of, but it really speeds things up a lot.

[gemini-code-assist]

Summary of Changes

Hello @ZZiigguurraatt, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant performance enhancement to the development Docker image build process. By leveraging Docker BuildKit's cache mounts, the dev.Dockerfile will now intelligently cache Go module and build artifacts. This optimization aims to drastically cut down build times by avoiding redundant dependency fetching and compilation, thereby streamlining the development workflow, particularly in environments where build contexts frequently invalidate traditional Docker layer caches.

Highlights

• Docker Build Speed Optimization: The dev.Dockerfile has been updated to use Docker cache mounts for the GOMODCACHE and GOCACHE directories. This change is designed to significantly reduce image rebuild times by caching Go dependencies, preventing them from being re-downloaded and re-built on every image recreation, especially when the build context is a remote git repository.
• BuildKit Requirement: This optimization introduces a new dependency: dev.Dockerfile now requires Docker BuildKit to be enabled for builds. Users can enable BuildKit by setting the environmental variable DOCKER_BUILDKIT=1 when executing docker build.
• Documentation Update: The docs/release-notes/release-notes-0.16.0.md file has been updated to include a detailed entry about this change, explaining the benefits of cache mounts and the new BuildKit requirement.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces cache mounts to the dev.Dockerfile to speed up Go dependency fetching and compilation during image rebuilds. The change is a good performance improvement. I've added a couple of suggestions: one to further optimize Docker layer caching in dev.Dockerfile, and another to fix the markdown formatting in the release notes.

[gemini-code-assist]

The formatting of this list item appears to be incorrect due to line breaks without proper indentation. This can lead to rendering issues in some markdown viewers. To ensure this is displayed as a single, coherent bullet point, it's best to have it on a single line or ensure all subsequent lines are indented correctly.

Suggested change

	* `dev.Dockerfile` now uses
	[cache mounts](https://docs.docker.com/build/cache/optimize/#use-cache-mounts)
	to cache the `GOMODCACHE` and `GOCACHE` directories so that dependencies don't
	need to be re-downloaded and re-built every time the image is re-created. This
	is particularly useful when the build context is a remote git repo and not a
	local filesystem, which often times causes a `COPY` layer cache and all the
	subsequent build layer caches to be invalidated. As a result of this change,
	`dev.Dockerfile` now requires
	[BuildKit](https://docs.docker.com/build/buildkit) to build. When using
	`docker build`, this can be enabled by setting the environmental variable
	`DOCKER_BUILDKIT=1`.
	* `dev.Dockerfile` now uses [cache mounts](https://docs.docker.com/build/cache/optimize/#use-cache-mounts) to cache the `GOMODCACHE` and `GOCACHE` directories so that dependencies don't need to be re-downloaded and re-built every time the image is re-created. This is particularly useful when the build context is a remote git repo and not a local filesystem, which often times causes a `COPY` layer cache and all the subsequent build layer caches to be invalidated. As a result of this change, `dev.Dockerfile` now requires [BuildKit](https://docs.docker.com/build/buildkit) to build. When using `docker build`, this can be enabled by setting the environmental variable `DOCKER_BUILDKIT=1`.

[djkazic]

LGTM.

[lightninglabs-deploy]

@ZZiigguurraatt, remember to re-request review from reviewers when ready

[ZZiigguurraatt]

The branch for this PR was accidentally deleted, so a new one was created and a new PR opened in #1168 .