GithubHelp home page GithubHelp logo

terraform's Introduction

terraform

Terraform files for managing organization infrastructure. See INSTALL.md for instructions on how to prepare this setup from scratch on GitHub.

Adding Users To Teams

In order to add a new user to an existing team, follow these steps:

  1. Open the variables.tf file.
  2. Find the team you want to edit in the variable "teams" section.
  3. Add the GitHub user name to the members array of the respective team.

Adding New Repositories

In order to add new repositories, so that the respective permissions / protections are applied automatically, follow these steps:

  1. Open the variables.tf file.

  2. Add the repository in the variable "repositories" > default section replacing the placeholders:

     {{REPOSITORY_NAME}} = {
   description = "{{DESCRIPTION}}"
   teams = [
     "{{TEAM_NAME}}"
   ]
 }

Terraform will then automatically create this repository with the appropriate settings. If you created the repository manually on GitHub before, you need to manually import that repository into Terraform. Therefore, run the following Terraform command locally:

For source repositories:

terraform import github_repository.repositories[\"your-repository-name\"] your-repository-name

For mirror repositories:

terraform import github_repository.mirrors[\"your-mirror-repository-name\"] your-mirror-repository-name

Changing Terraform Configuration

The process for changing Terraform configuration is as follows:

  1. Change configuration as you wish and send a pull request.
  2. GitHub Actions will automatically be run to check the syntax of the updated configuration. For first-time users, an administrator needs to approve the run of this GitHub Action once.
  3. Administrators can now add a comment to the pull request with the text "/plan". This will dry-run the configuration changes and show the output of the applied changes.
  4. When the merge checks are fulfilled, the pull request can be merged. Another GitHub Action will automatically be triggered and will actually apply the changes.

Executing Terraform Actions Locally

In general, we run Terraform via GitHub Actions. However, in certain cases, it might be handy to execute Terraform locally. Therefore, install Terraform and set the following environment variables:

terraform's People

Contributors

aleron75 avatar damienwebdev avatar davidlambauer avatar gowrizrh avatar jakski avatar jakski-it-bot[bot] avatar mage-os-ci avatar rhoerr avatar sprankest avatar sprankhub avatar vinai avatar

Stargazers

avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

Forkers

jakski damienwebdev davidlambauer vinai aleron75 sprankhub rhoerr gowrizrh

terraform's Issues

Terraform Debug Logging During GitHub Actions

We should consider using one of the following Terraform log levels during the GitHub Actions by default:

  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR

This is as easy as adding an environment variable TF_LOG to the respective value, see https://developer.hashicorp.com/terraform/internals/debugging.

The advantage would be that we have detailed information about issues, which may occur, without executing the actions locally.

Would appreciate your input, @bucha, @vitaliy-golomoziy if you think it makes sense and which log level we should use.

Workflows On Inactive Repositories Should Remain Enabled

According to observations by @Vinai, scheduled workflows on inactive repositories seem to be disabled automatically. This is also mentioned in the docs:

Warning: To prevent unnecessary workflow runs, scheduled workflows may be disabled automatically. When a public repository is forked, scheduled workflows are disabled by default. In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.

This is an issue for us, because we have repositories with no activity in a long time, but we need the scheduled workflow to merge upstream changes nevertheless. There seem to be only two solutions:

  1. Create empty dummy commits to pretend activity. This is e.g. implemented in https://github.com/marketplace/actions/keepalive-workflow. However, we should not have any dummy commits in our repositories.
  2. Enable the workflow again after it has been disabled. I only found an AWS solution for this. In general, we could use the REST API to enable the workflow again as soon as it has been disabled. However, this seems to not be supported by Terraform yet, so we might want to create a separate GitHub Action for this?

Branch delete permissions

I'm not able to delete PR branches at https://github.com/mage-os/mage-os-website/branches since Terraform was initialized. This seems like it'll be necessary for repos under active development, to keep the branches clean.

Seems to be a side effect of the * branch restrictions on the repo.

I don't know how long the website will run from this repository with the content site merge discussions going on, so the website repo itself might not be worth a lot of specific effort at this point. But the same will probably come up for our other repos.

Allow Topics

To create stronger visibility on GitHub, we should add topics to our repositories. Can be done very similar as for the homepage_url

Document Permissions

We should document the permissions we set via Terraform in a human-readable format here or in a Google Doc or on the website or wherever.

Allow push new commits to branch

Currently, members are able to push to a new branch, but after that the branch can not be updated.
The * branch protection rule is too broad. We need to be able to specify a list of branches to protect.
This list needs to be configurable on a per repository basis, since the repos use different branch names.

Add Topics

Now that we support topics (see #29 / #49), we should add them for all repositories.

Which topics should all repositories have? I suggest mage-os, magento2 and adobe-commerce.

Which topics should all mirror repositories have? I suggest mirror.

Should we also adopt all topics from the respective "original" repositories?

Feel free to give feedback here, but this should probably also be discussed during the next tech meeting.

Fix GitHub Action Condition

As can be seen here, the current condition on the GitHub Action "Terraform plan" does not work:

terraform/.github/workflows/terraform-plan.yml

Lines 14 to 22 in da5dfbe

if: >
${{
github.event.issue.pull_request &&
github.event.comment.body == '/plan' &&
(
github.event.comment.user.login == 'Vinai' ||
github.event.comment.user.login == 'sprankhub'
)
}}

The action was executed on an issue comment, even though we only want to execute it on pull request comments with a certain text from certain authors. I checked the condition and it pretty much seems to use the same condition as shown in the docs.

Switch to openTF?

tldr:

Hashicorp switched the terraform license from an open-source license to a business license. The community is unsure about the future of terraform and created a fork called openTF. Sound familiar, right? 😄 .

For now, nothing has changed, and openTF is younger than Mage-OS 😅 . Nevertheless, it's worth following the discussion and eventually preparing a migration. There is no need to be a first-mover, but it should be on our radar.

Their "open letter"
Their GitHub Repo

Test Permissions

Test if the permissions work in the way we want them to work.

New repo for mage-os contribution environments

Hi,
Sorry I know I should of done this last week, please could we create a repo for development environments for mage-os, can't remember the name @Vinai wanted, think it was development-environment

Nice one thanks

Branch Protection Setting for mage-os/github-actions should only be `main`

Currently the branch protection rules on https://github.com/mage-os/github-actions/settings/branches are set to * by the terraform rules. I've temporarily changed it to main, but as far as I know that will be reverted the next time the terraform config is applied.

We need only main to be protected is so release-please-* branches can be force-pushed to by a bot. The bot automatically creates releases when commits are made to the main branch.
The branch protection rule * prevents this from working.

Issues With Archived Repositories

This is about https://github.com/mage-os/terraform/actions/runs/9500022004/job/26182150184.

When a repository is archived, and we update some configuration like the branch protection rules, Terraform will try to apply the changes to the archived repository and GitHub will throw an error:

╷
│ Error: Repository is archived
│ 
│   with github_branch_protection.repositories["mage-os-website"],
│   on main.tf line 126, in resource "github_branch_protection" "repositories":
│  126: resource "github_branch_protection" "repositories" {
│ 
╵
Error: Process completed with exit code 1.

We had a similar issue in #54, but the new issue cannot be fixed in the same way.

My current idea is that we remove the old, archived repository from the Terraform state and from the variables.tf file. This way, Terraform might just ignore the existing, archived repository. Would that work, @Jakski?

Any other ideas?

Add Support For Individual Contributors

Currently, pre-defined teams can get access to certain repositories. However, we also need the functionality to give individual contributors access to certain repositories. Therefore, I think we should extend this:

terraform/variables.tf

Lines 205 to 208 in cd6553f

mageos-async-events = {
description = "This is a Mage-OS repo for the porting of the Magento Asynchronous Events Project found at https://github.com/aligent/magento-async-events."
teams = ["distribution"]
}

by

    contributors = ["contributor-username"]

And then we need to do something similar like here:

terraform/main.tf

Lines 130 to 142 in cd6553f

resource "github_team_repository" "teams" {
for_each = { for i in flatten([
for repository_name, repository in var.repositories : [
for team in try(repository.teams, []) : {
repository = repository_name
team = team
}
]
]) : "${i.repository}_${i.team}" => i }
team_id = github_team.teams[each.value.team].name
repository = github_repository.repositories[each.value.repository].name
permission = "push"
}

with the resource github_repository_collaborator instead of github_team_repository.

Allow mage-os-ci user to push to remote bypassing branch protections

Currently all repositories defined in variable "repositories" have branch protections turned on so all changes are submitted via pull requests. This makes sense in a regular repository but not so much in a mono-repository setup.

The mageos-async-events-sinks is a mono repository which runs an action to split the packages and push to remote as the mage-os-ci user, thus running into the problem of not being allowed to push because of said branch restrictions.

Some possible solutions that I can think of are

  1. Create a new variable "mono-repositories" which copy the same branch protection configuration AND add push_allowances to the mage-os-ci user.
  2. Add push_allowances to the mage-os-ci user on the existing branch protection rule meaning mage-os-ci could in theory bypass branch restrictions on all repositories defined by the variable.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.