> For the complete documentation index, see [llms.txt](https://jadelab.gitbook.io/jadegit/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jadelab.gitbook.io/jadegit/0.18.0/admin/jadegit-builds.md).

# JadeGit Builds

Teams adopting JadeGit may choose to build it internally rather than downloading public releases. This allows JadeGit to be used with appropriate governance while providing a consistent source of binaries for internal use.

Internal builds can help address several practical concerns, including, but not limited to:

* Targeting the Jade platform versions used
* Vulnerability scanning and compliance checks
* Publishing binaries for internal use

## Internal Repository

The recommended approach is to set up an internal [superproject](https://git-scm.com/docs/user-manual.html#Documentation/user-manual.txt-superproject) that acts as a pointer to the JadeGit version approved for internal use. This repository references a public JadeGit source repository as a Git submodule and defines pipelines used to build and publish JadeGit internally.

Using this approach, the internal repository, along with the pipelines used to build and distribute JadeGit internally, can remain private as it only references a public JadeGit source repository. This creates a clear boundary that complies with the open-source license, while allowing organisations to use or contribute via a public fork if desired.

## Update Process

When a newer JadeGit version is required, the submodule reference can be updated to point to a different branch, tag, or commit.

This can be performed by changing the submodule reference manually, or by using a pipeline to switch the submodule to the desired reference and commit the change to the internal repository.

Running this process on a feature branch allows the updated version to be built and validated before being approved through a standard pull request workflow. Once merged, the updated reference becomes the approved JadeGit version used for internal builds.

## Build Pipeline

This pipeline should build the same binaries produced by the open-source build pipeline, while targeting the platform versions required internally.

As this pipeline runs within the organisation’s infrastructure, it provides an opportunity to incorporate additional checks such as vulnerability scanning or other security and compliance processes required by internal governance.

### Test

Automated tests should be executed as part of the pipeline to validate the build. While optional, they may detect issues when targeting platform versions not otherwise covered by the open-source build pipeline.

### Publish

After all checks have been completed, binaries can be published to an internal artifact feed, package registry, or equivalent.  From there, they can be reliably consumed by other pipelines, such as those used to deploy application changes or prepare database images that can be used to set up development workspaces or support automated testing.