Skip to content

Latest commit

 

History

History
68 lines (42 loc) · 3.13 KB

readme-g3-cache.md

File metadata and controls

68 lines (42 loc) · 3.13 KB

Custom g3-cache

Introduction

The custom g3-cache has been introduced in the second version (G3v2) of the project.

The local g3-cache is an additional cache used by the building pipeline and it should not be confused with the Docker builder cache maintained by the Docker Build itself.

The g3-cache stores the selected pre-downloaded packages used by the Dockerfiles, that would be otherwise repeatedly downloaded from the external sources by each build.

It results in a significantly higher performance by building sets of images or by repeated builds.

You can learn more about the concept on the Wiki page "Concepts of g3-cache" and about the implementation on the Wiki page "How g3-cache works".

Ensure wget utility

If you are on Windows, you can encounter the problem of missing wget utility. It is used by refreshing the g3-cache and it's available on Linux by default.

On Windows you have generally two choices. You can build your images inside the WSL environment or you can download the wget.exe application for Windows. Make sure to update also the PATH environment variable appropriately.

Local g3-cache

The local g3-cache of this project has the following cache sections:

  • chromium
  • novnc
  • tigervnc
  • websockify

The local g3-cache folder docker/.g3-cache is excluded from the commits into the git repository by the means of the .gitignore file.

You can delete the local g3-cache folder any time, because it will be re-created each time you build an image.

Shared g3-cache

The absolute path to the root folder of the shared g3-cache should be set as the value of the environment variable SHARED_G3_CACHE_PATH.

The same shared g3-cache is usually used also by the sibling projects accetto/headless-drawing-g3 and accetto/headless-coding-g3.

Helper script cache

Both g3-caches are refreshed by the helper script cache, which is stored in the folder docker/hooks/. Therefore it's sometimes referenced as a hook script.

The script is used by the hook scripts pre_build and build. However, it can be executed also stand-alone.

Remark: The current implementation of the cache refreshing code is not thread safe and it is not intended for parallel building of multiple images.