Commit ddabef32 authored by Craig Barrett's avatar Craig Barrett

Add paragraph about env-projects

parent 6712c767
......@@ -19,14 +19,23 @@ coded. This means you only need to change `count` in `main.tf` to scale a fleet
in and out. More information about [managing cattle can be found in our
docs](./docs/working-with-cattle.md)
### env-projects
All environments in which we have deployed compute resources utilize CI/CD to run `terraform plan`
and manual jobs for `terraform apply`. The exception to this pattern is the meta-environment
`env-projects`, which is used to bootstrap and manage the configuration on all GCP projects with
deployed infrastructure. `env-projects` uses the [project](https://gitlab.com/gitlab-com/gl-infra/terraform-modules/google/project) module to manage configurations for GCP
projects, and terraform runs those operations from the default genesis project, [env-zero](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#env-zero).
### Modules
While some modules are still maintained under the `./modules` directory, we are actively migrating
module code to standalone repositories under the
[`gitlab-com/gl-infra/terraform-modules`](https://ops.gitlab.net/gitlab-com/gl-infra/terraform-modules) group in
the ops.gitlab.net instance (see [infrastructure#5688](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5688) for
current progress).
These standalone modules use automatic semantic versioning. See CONTRIBUTING.md in each repo for details; in short, if you prefix your commit messages with a known magic value (fix:, feat: etc) then when merged an updated version tag will be pushed based on semver rules, which can then be used as the ref value of the 'source' attribute of module use in this repo.
Modules are located in standalone repositories under the
[`gitlab-com/gl-infra/terraform-modules`](https://ops.gitlab.net/gitlab-com/gl-infra/terraform-modules)
group in the ops.gitlab.net instance. These standalone modules use automatic semantic versioning.
See CONTRIBUTING.md in each repo for details; in short, if you prefix your commit messages with a
known magic value (fix:, feat:, BREAKING CHANGE:) then when merged an updated version tag will be
pushed based on semver rules, which can then be used as the ref value of the 'source' attribute of
module use in this repo.
## Setup (How can I use this?)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment