RWS/crossplane-provider-gitlab
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
FLOW Crossplane gitlab provider chart
25 commits 1 branch 0 tags 44 KiB
Find a file
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Loon, Nicky van (RWS CIV) f8a48279b1 Merge branch 'EN-4637-add-resources-and-krr-recommendations' into 'main' 
EN-4637/Add resources and krr recommendations

See merge request osr-wm/development/enabling/crossplane/provider-gitlab!10
2026-04-03 09:16:57 +02:00
chart EN-4637/Add resources and krr recommendations 2026-04-03 09:16:56 +02:00
tests En 3219 add gitlab provider tests 2025-12-15 13:51:16 +01:00
.chainsaw.yaml En 3219 add gitlab provider tests 2025-12-15 13:51:16 +01:00
.gitignore EN-3700 / added ability to create multiple provider configs 2026-01-06 16:50:41 +01:00
.gitlab-ci.yml EN-4637/Add resources and krr recommendations 2026-04-03 09:16:56 +02:00
README.md Updated README with more info 2026-01-15 14:48:16 +01:00
renovate.json Add renovate.json 2025-11-18 09:04:40 +00:00

README.md

Provider GitLab

This chart configures the Crossplane Gitlab provider so it can connect to our GitLab environment.

How it works

DeploymentRuntimeConfig

The provider uses a DeploymentRuntimeConfig to adjust the settings of the provider pod running in the cluster.

For more information, see the Crossplane documentation.

Provider

The chart creates the provider-gitlab provider referenced above.

For an overview of the other resources managed by this provider, see the Crossplane Gitlab provider docs.

Note: Resources are deployed in waves. This is necessary because the provider itself creates the special ProviderConfig CRD required for communication with GitLab. Therefore, the ProviderConfig must be deployed after the Provider.

ProviderConfig

The ProviderConfig defines the properties required to communicate with our GitLab instance.

For credentials, we use the External Secrets Operator to retrieve secrets from Vault.

Testing

A Chainsaw test has been implemented to validate that a GitLab variable can be created using the resources deployed by this chart.

The test follows the same approach used for GitLab variables in as in the tenant chart.

The test includes the following steps:

  1. Deploy the Helm chart in the crossplane-system namespace

  2. Create a Variable using our ProviderConfig

  3. Verify that the Variable is created in the cluster

  4. Verify that the Variable is created in GitLab under the Enabling group