diff --git a/.github/workflows/ci-docs-shim.yaml b/.github/workflows/ci-docs-shim.yaml index b7f36e3c..25d3f503 100644 --- a/.github/workflows/ci-docs-shim.yaml +++ b/.github/workflows/ci-docs-shim.yaml @@ -8,6 +8,10 @@ on: branches: [main] types: [milestoned, opened, synchronize] +# Permissions for the GITHUB_TOKEN used by the workflow. +permissions: + contents: read # Allows reading the content of the repository. + jobs: validate: strategy: diff --git a/.github/workflows/commitlint.yaml b/.github/workflows/commitlint.yaml index 668de4aa..4d2bdeda 100644 --- a/.github/workflows/commitlint.yaml +++ b/.github/workflows/commitlint.yaml @@ -8,6 +8,10 @@ on: branches: [main] types: [milestoned, opened, edited, synchronize] +# Permissions for the GITHUB_TOKEN used by the workflow. +permissions: + contents: read # Allows reading the content of the repository. + jobs: validate: uses: defenseunicorns/uds-common/.github/workflows/callable-commitlint.yaml@c52077c870a576d01f169f96d74d1b393c6488ba # v1.1.2 diff --git a/.github/workflows/lint.yaml b/.github/workflows/lint.yaml index be6fb18a..ee594a2f 100644 --- a/.github/workflows/lint.yaml +++ b/.github/workflows/lint.yaml @@ -9,6 +9,10 @@ on: # milestoned is added here as a workaround for release-please not triggering PR workflows (PRs should be added to a milestone to trigger the workflow). types: [milestoned, opened, reopened, synchronize] +# Permissions for the GITHUB_TOKEN used by the workflow. +permissions: + contents: read # Allows reading the content of the repository. + jobs: validate: uses: defenseunicorns/uds-common/.github/workflows/callable-lint.yaml@c52077c870a576d01f169f96d74d1b393c6488ba # v1.1.2 diff --git a/README.md b/README.md index a525694d..7e62dbf0 100644 --- a/README.md +++ b/README.md @@ -5,82 +5,18 @@ [![Build Status](https://img.shields.io/github/actions/workflow/status/defenseunicorns/uds-package-gitlab/release.yaml)](https://github.com/defenseunicorns/uds-package-gitlab/actions/workflows/release.yaml) [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/defenseunicorns/uds-package-gitlab/badge)](https://api.securityscorecards.dev/projects/github.com/defenseunicorns/uds-package-gitlab) -This package is designed for use as part of a [UDS Software Factory](https://github.com/defenseunicorns/uds-software-factory) bundle deployed on [UDS Core](https://github.com/defenseunicorns/uds-core), and is based on the Bigbang [GitLab](https://repo1.dso.mil/big-bang/product/packages/gitlab) chart. +This package is designed for use as part of a [UDS Software Factory](https://github.com/defenseunicorns/uds-software-factory) bundle deployed on [UDS Core](https://github.com/defenseunicorns/uds-core). > [!IMPORTANT] > The `arm64` package includes `amd64` images due to lack of availability of `arm64` images from upstream projects at this time. This means you can deploy the `arm64` package on an `arm64` kubernetes cluster, but some of the images contained in the package will require emulation (e.g., qemu or rosetta) to run properly. ## Pre-requisites -The GitLab Package expects to be deployed on top of [UDS Core](https://github.com/defenseunicorns/uds-core) with the dependencies listed below being configured prior to deployment. +The GitLab Package expects to be deployed on top of [UDS Core](https://github.com/defenseunicorns/uds-core) with a configured Redis/Valkey instance, Postgres database and S2 compatible object storage. To learn more about configuring GitLab see the [configuration documentation](./docs/configuration.md). > [!IMPORTANT] > **NOTE**: Some GitLab features (such as GitLab pages) will also require a [GitLab runner](https://github.com/defenseunicorns/uds-package-gitlab-runner) along with additional configuration such as an additional certificate SAN for `*.pages.`. -GitLab is configured by default to assume the internal dependencies that are used for testing (see minio, redis and postgres in the [bundle](bundle/uds-bundle.yaml)). - -> [!IMPORTANT] -> If you are using different internal services, cloud services or a mix you will have to configure values in the config chart accordingly via bundle overrides. See the networking [docs](docs/networking.md) for details - -#### Database - -- A Postgres database is running on port `5432` and accessible to the cluster via the `GITLAB_DB_ENDPOINT` Zarf var. -- This database can be logged into via the username configured with the Zarf var `GITLAB_DB_USERNAME`. Default is `gitlab` -- This database instance has a psql database created matching what is defined in the Zarf var `GITLAB_DB_NAME`. Default is `gitlabdb` -- The user has read/write access to the above mentioned database -- Create `gitlab-postgres` service in `gitlab` namespace that points to the psql database -- Create `gitlab-postgres` secret in `gitlab` namespace with the key `password` that contains the password to the user for the psql database - -#### Redis / Redis Equivalent - -- An instance of Redis or Redis equivalent (elasticache, etc.) is running on port `6379` and accessible to the cluster via the `GITLAB_REDIS_ENDPOINT` Zarf var. -- The redis instance accepts anonymous auth (password only) -- Create `gitlab-redis` service in `gitlab` namespace that points to the redis instance -- Create `gitlab-redis` secret in `gitlab` namespace with the key `password` that contains the password to the redis instance - -#### Object Storage - -Object Storage works a bit differently as there are many kinds of file stores GitLab can be configured to use. - -- Create the secret `gitlab-object-store` in the `gitlab` namespace with the following keys: - - An example for in-cluster Minio can be found in this repository at the path `src/dev-secrets/minio-secret.yaml` - - `connection` - - This key refers to the configuration for the main GitLab service. The documentation for what goes in this key is located [here](https://docs.gitlab.com/16.0/ee/administration/object_storage.html#configure-the-connection-settings) - - `registry` - - This key refers to the configuration for the gitlab registry. The documentation for what goes in this key is located [here](https://docs.docker.com/registry/configuration/#storage) - - `backups` - - This key refers to the configuration for the gitlab-toolbox backup tool. It relies on a program called `s3cmd`. The documentation for what goes in this key is located [here](https://s3tools.org/kb/item14.htm) -- Below are the list of buckets that need to be created before starting GitLab: - -```yaml - - uds-gitlab-pages - - uds-gitlab-registry - - uds-gitlab-lfs - - uds-gitlab-artifacts - - uds-gitlab-uploads - - uds-gitlab-packages - - uds-gitlab-mr-diffs - - uds-gitlab-terraform-state - - uds-gitlab-ci-secure-files - - uds-gitlab-dependency-proxy - - uds-gitlab-backups - - uds-gitlab-tmp -``` - -- These buckets can have a suffix applied via the `BUCKET_SUFFIX` Zarf variable (e.g. `-some-deployment-name` plus `uds-gitlab-backups` would be `uds-gitlab-backups-some-deployment-name`) - - - -## Flavors - -| Flavor | Description | Example Creation | -| ------ | ----------- | ---------------- | -| upstream | Uses upstream images within the package. | `zarf package create . -f upstream` | -| registry1 | Uses images from registry1.dso.mil within the package. | `zarf package create . -f registry1` | - -> [!IMPORTANT] -> **NOTE:** To create the registry1 flavor you will need to be logged into Iron Bank - you can find instructions on how to do this in the [Big Bang Zarf Tutorial](https://docs.zarf.dev/tutorials/6-big-bang/#setup). - ## Releases The released packages can be found in [ghcr](https://github.com/defenseunicorns/uds-package-gitlab/pkgs/container/packages%2Fuds%2Fgitlab). @@ -98,4 +34,4 @@ Please see the [CONTRIBUTING.md](./CONTRIBUTING.md) ## Development -When developing this package it is ideal to utilize the json schemas for UDS Bundles, Zarf Packages and Maru Tasks. This involves configuring your IDE to provide schema validation for the respective files used by each application. For guidance on how to set up this schema validation, please refer to the [guide](https://github.com/defenseunicorns/uds-common/blob/main/docs/development-ide-configuration.md) in uds-common. +When developing this package it is ideal to utilize the json schemas for UDS Bundles, Zarf Packages and Maru Tasks. This involves configuring your IDE to provide schema validation for the respective files used by each application. For guidance on how to set up this schema validation, please refer to the [guide](https://github.com/defenseunicorns/uds-common/blob/main/docs/uds-packages/development/development-ide-configuration.md) in uds-common. diff --git a/docs/configuration.md b/docs/configuration.md index bce8e285..dd4a41c5 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -53,6 +53,39 @@ The Software Factory team has not yet tested IRSA with AWS RDS - there is an ope https://github.com/defenseunicorns/uds-software-factory/issues/45 +## Object Storage + +> [!NOTE] +> This section is subject to change / improvement once [`uds-package-minio-operator`](https://github.com/defenseunicorns/uds-package-minio-operator) is fully ready for production use cases. + +Object Storage works a bit differently as there are many kinds of file stores GitLab can be configured to use. + +- Create the secret `gitlab-object-store` in the `gitlab` namespace with the following keys: + - An example for in-cluster Minio can be found in this repository at the path `src/dev-secrets/minio-secret.yaml` + - `connection` + - This key refers to the configuration for the main GitLab service. The documentation for what goes in this key is located [here](https://docs.gitlab.com/16.0/ee/administration/object_storage.html#configure-the-connection-settings) + - `registry` + - This key refers to the configuration for the gitlab registry. The documentation for what goes in this key is located [here](https://docs.docker.com/registry/configuration/#storage) + - `backups` + - This key refers to the configuration for the gitlab-toolbox backup tool. It relies on a program called `s3cmd`. The documentation for what goes in this key is located [here](https://s3tools.org/kb/item14.htm) +- Below are the list of buckets that need to be created before starting GitLab: + +```yaml + - uds-gitlab-pages + - uds-gitlab-registry + - uds-gitlab-lfs + - uds-gitlab-artifacts + - uds-gitlab-uploads + - uds-gitlab-packages + - uds-gitlab-mr-diffs + - uds-gitlab-terraform-state + - uds-gitlab-ci-secure-files + - uds-gitlab-dependency-proxy + - uds-gitlab-backups + - uds-gitlab-tmp +``` +- These buckets can have a suffix applied via the `BUCKET_SUFFIX` Zarf variable (e.g. `-some-deployment-name` plus `uds-gitlab-backups` would be `uds-gitlab-backups-some-deployment-name`) + ## Redis / Valkey GitLab uses Redis as a key value store for caching, job queueing and more and supports external providers (such as Elasticache) as well as the [UDS Valkey](https://github.com/defenseunicorns/uds-package-valkey/) package to provide the service.