Terraform github repository

Terraform github repository DEFAULT

Terraform

Terraform

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

The key features of Terraform are:

  • Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.

  • Execution Plans: Terraform has a "planning" step where it generates an execution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.

  • Resource Graph: Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.

  • Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.

For more information, see the introduction section of the Terraform website.

Getting Started & Documentation

Documentation is available on the Terraform website:

If you're new to Terraform and want to get started creating infrastructure, please check out our Getting Started guides on HashiCorp's learning platform. There are also additional guides to continue your learning.

Show off your Terraform knowledge by passing a certification exam. Visit the certification page for information about exams and find study materials on HashiCorp's learning platform.

Developing Terraform

This repository contains only Terraform core, which includes the command line interface and the main graph engine. Providers are implemented as plugins, and Terraform can automatically download providers that are published on the Terraform Registry. HashiCorp develops some providers, and others are developed by other organizations. For more information, see Extending Terraform.

To learn more about compiling Terraform and contributing suggested changes, please refer to the contributing guide.

To learn more about how we handle bug reports, please read the bug triage guide.

License

Mozilla Public License v2.0

Sours: https://github.com/hashicorp/terraform

Terraform Module: GitHub Repository

Terraform Module for managing GitHub Repositories and associated resources.

Table of Contents

Requirements

This module requires Terraform version or newer.

Dependencies

This module depends on a correctly configured GitHub Provider in your Terraform codebase.

Usage

Add the module to your Terraform resources like so:

module"simple_example" { source ="operatehappy/repository/github" version ="3.0.0" name ="oh-demo-simple-example" visibility =false }

Then, fetch the module from the Terraform Registry using .

Additional usage examples are available in the directory via GitHub.

Inputs

NameDescriptionTypeDefault
allow_merge_commitToggle to enable Merge Commits for the Repository
allow_rebase_mergeToggle to enable Rebase Merges for the Repository
allow_squash_mergeToggle to enable Squash Merges for the Repository
archive_on_destroyToggle to archive the Repository on destroy
archivedToggle to archive the Repository (see notes in )
auto_initToggle to create an initial commit in the Repository
branch_protectionsList of Branch Protection Objectslist(object({
branch = string,
enforce_admins = bool,
require_signed_commits = bool,
required_status_checks = object({
strict = bool
contexts = list(string)
})

required_pull_request_reviews = object({
dismiss_stale_reviews = bool,
dismissal_users = list(string),
dismissal_teams = list(string),
require_code_owner_reviews = bool,
required_approving_review_count = number // NOTE: this must be 6 or less
})

restrictions = object({
users = list(string),
teams = list(string)
})
}))
default_branchName of the Default Branch of the Repository
delete_branch_on_mergeToggle to automatically delete merged Branches for the Repository
deploy_keysList of Deploy Key Objectslist(object({
title = string,
key = string,
read_only = bool
}))
descriptionDescription of the Repository
filesList of File Objecslist(object({
file = string,
content = string
}))
gitignore_templateTemplate to use for initial file for the Repository
has_downloadsToggle to enable (deprecated) GitHub Downloads for the Repository
has_issuesToggle to enable GitHub Issues for the Repository
has_projectsToggle to enable GitHub Projects for the Repository
has_wikiToggle to enable GitHub Wiki for the Repository
homepage_urlURL of a page describing the Repository
is_templateToggle to enable Template use for the Repository
issue_labelsList of Issue Label Objectslist(object({
name = string,
color = string
}))
license_templateIdentifier to use for initial file for the Repository
nameName of the Repository
pagesConfiguration block for GitHub Pages
projectsList of Project Objecslist(object({
name = string,
body = string
}))
repository_collaboratorsList of Collaborator Objectslist(object({
username = string
}))
team_repository_teamsList of Team Repository Team Objectslist(object({
team_id = string
}))
templateTemplate Repository to use when creating the Repository
topicsList of Topics of the Repository
visibilityToggle to create a Private Repository
vulnerability_alertsToggle to enable Vulnerability Alerts for the Repository

Outputs

NameDescription
filesMap of Repository File names and corresponding SHA blobs
full_nameA string of the form "orgname/reponame"
git_clone_urlURL to clone the repository via the git protocol
html_urlURL to the repository on the web
http_clone_urlURL to clone the repository via HTTPs
nameA string of the form "reponame"
node_idNode ID of the Repository
project_idsList of Repository Project IDs
project_urlsList of Repository Project IDs
projectsMap of Repository Project IDs, and corresponding URLs
repo_idID of the Repository
ssh_clone_urlURL to the repository to clone via SSH
svn_urlURL to check out the repository via GitHub's Subversion protocol emulation

Notes

Upgrading from to

The version of this module introduced support for the github_branch_default resource, a property that was initially handled through the resource.

For a better upgrade experience, it is advised to manually import this resource, using the import command:

terraform import module.my_repository.github_branch_default.this "my_repository"

Replace with the Module identifier in use and replace with the name of the repository the data is imported from.

For resources

  • Resources that are created with the option enabled will be re-created (that is: destroyed, then created again) when the stub is removed

  • Resources that are archived using the option cannot be unarchived, as the GitHub API does not currently support this

  • Starting with of this Module, the default branch option is no longer set through the resource

For resources

  • Deploy Key resources expect a string for the variable. Use the file function if key material is not available as a Terraform-variable already

  • For a step-by-step guide on how to generate SSH Keys, see this article on GitHub

For resources

For resources

  • Project resources require GitHub Projects to be enabled for the Organization as well as the variable set to

For resources

  • File resources require an (already existing) branch, or an explicitly defined branch for the variable to avoid errors

  • File resources expect a string for the variable. Use the file function if file data is not available as a Terraform-variable already

  • File resources that are removed from Terraform will also be removed from the Repository. This is visible in the Repository History

Author Information

This module is maintained by the contributors listed on GitHub.

Development of this module was sponsored by Operate Happy.

License

Licensed under the Apache License, Version 2.0 (the "License").

You may obtain a copy of the License at apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" basis, without WARRANTIES or conditions of any kind, either express or implied.

See the License for the specific language governing permissions and limitations under the License.

Sours: https://github.com/operatehappy/terraform-github-repository
  1. Brewster motorsports
  2. Biomutant armor
  3. John 15 msg
  4. Pytorch std

How to manage your GitHub Organization with Terraform

GitHub is the most popular platform for software development version control using Git. In our day to day business, we work for a broad set of organizations, from small startups to big enterprises. One thing we've been observing across all possible stages and sizes of companies is, that managing a GitHub organization efficiently is a challenge.

This is the first part of our series "How to manage your GitHub Organization with Terraform".

In this article, we will explain how we manage our and our customer's GitHub organizations through code with Terraform.

Here is a brief overview of what we will cover:

Terraform and the GitHub provider

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. With Terraform you can write Infrastructure as Code (IaC) and describe your infrastructure with a high-level, declarative syntax.

In this article, we will assume that you are familiar with the Terraform basics. If you are just getting started, we advise you to read the official introduction to Terraform.

The GitHub Provider is a Terraform wrapper around the GitHub API and, by the time of writing, allows us to manage the following resources:

  • Organizations (memberships, blocked users, issue labels, projects, webhooks)
  • Repositories (collaborators, branch protection rules, deploy keys, projects, webhooks)
  • Teams (memberships, repositories)
  • Users (SSH keys, invitations)

Note: Due to provider limitations, we can’t create organizations using Terraform. To create a new organization please follow this guide.

Manage your organization and repositories with Terraform

Let's get started. We assume that you have Terraform installed locally and your GitHub organization created. For the sake of simplicity, we will focus on managing a plain organization for now but we will point out how to migrate existing organizations later in this article.

To be able to communicate with the GitHub API, we need to issue a personal access token. If you haven't issued one yet, please follow this guide to create a new one.

For personal accounts, we recommend using the permissions setup shown below. However, if you'd like to use the token inside your CI (e.g. for a machine user ), we recommend you for the sake of security to issue a token that comes without the permission to delete repositories. Recommended Permission Set for GitHub Personal Access Token

Once you have your organization and access token in place, you can continue to configure the provider and take a look at some sample code.

The code below is responsible for the following tasks:

  • Configure the GitHub provider to manage your organization
  • Add the GitHub user to the organization.
  • Create a repository inside your organization and configure a branch protection rule

It makes sense to replace the placeholders and with your desired inputs.

To be able to run the code, you need to set your personal access token as a "token" param on the section, but I strongly suggest setting a environment variable instead ( e.g. , which is read by the provider directly.

Passing the token as an environment variable avoids Terraform storing it unencrypted on disk when saving a plan output file and is therefore recommended.

To initialize your Terraform environment, you need to run .

With you can create an execution plan that you should review before applying any changes to your organization. Terraform will ask you for the name of the organization you'd like to manage.

Run terraform plan

It's important to review any changes before applying them to your organization.

A common mistake we see quite often is to run and without checking the plan of . Actually, checks the differences between the state Terraform keeps in the configured backend and the deployed infrastructure once again and will ask you to continue before the changes will be deployed.

In some environments, especially when multiple people or machines may deploy the same resources, it's mandatory to run on a previously created and reviewed plan. This can be achieved by running passing a previously generated planfile to the apply command (e.g. and ).

Let's run to create the desired resources.

Run terraform apply

That's it! You can easily take it from here and add more members, repositories and even take a look at the team resource.

Keep your code DRY with modules

Using the sample code we discussed in the previous section is a great starting point but nothing solid if you would like to manage an organization that has dozens or even hundreds of repositories, members and teams. In a real-world scenario, quite often you would apply the same or similar settings to a set of repositories. We use modules in our GitHub code to set some standards among our resources and to make some configurations easier or more compact.

We recently open-sourced some Terraform 0.12 modules to simplify managing GitHub through code:

  1. terraform-github-repository
  2. terraform-github-organization
  3. terraform-github-team

If you'd like to read more about modules in Terraform, we recommend this guide.

How to manage your organization with modules

Let's start writing our organization as code with a more sophisticated approach using modules. GitHub requires you to add a new member either as a or as an . Also, quite often GitHub users choose usernames that aren't expressive. To keep an overview of which account belongs to whom, it's a good practice to map the email addresses of your colleagues to their GitHub usernames. Since we normally reference each user in multiple resources, it's a more convenient way to use the user's email address instead of the username.

Let's create the file with the following content.

The code in defines the user groups , , and . Typical use cases for machine users are automated tasks such as checking out a repository in your CI / CD Pipelines. We will discuss more on that later.

Also, we again need to configure the GitHub provider to make our code working. Please create a file with the following content.

After replacing the example values with your data, you should be able to deploy the changes to your organization.

Note: Our open source modules use for, for-each and dynamic nested blocks that were introduced in Terraform 0.12. A common problem in Terraform configurations previously to version 0.12 is dealing with situations where the number of values or resources is decided by a dynamic expression rather than a fixed count. You can now dynamically add and remove items from and to Lists without the necessity to render the whole list of resources again. Terraform will only add and remove the items you want it to.

Feel free to play around with the . You can add and remove members dynamically and even cluster the members into more specific groups.

How to manage your teams with modules

After adding all members to your repository, you should set up your team structure. For the sake of simplicity we will only deal with two teams in our examples, but feel free to add as many teams as you like.

Let's create a file with the following code.

Running deploys two teams into your organization and adds the desired members. Now let's take a look at repositories, the most important resources of your organization.

How to manage your repositories with modules

Quite often repositories share the same or a similar set of settings. Since we would like to keep our configuration as DRY as it is possible with Terraform, let's create some default settings that we can apply to each new repository. It's usually a good starting point to create some default settings for as well as repositories.

Let's create a file with the following content.

If you create a repository with our terraform-github-repository module you should be aware, that the module is opinionated and comes with a default set of options. For details please read the documentation of the module.

Now that we have our default settings in place, let's add some repositories to the .

That's it! We successfully defined our GitHub Organization as Code. From here you can easily add your members, teams, and repositories. Our modules offer a broad set of options. We recommend you to read the documentation for each module.

Terraform is able to import existing infrastructure. This allows you to take resources you've created by some other means and bring it under Terraform management. This is especially helpful if you'd like to manage a GitHub organization with existing resources through code.

Let's assume you have an existing repository . To import the existing repository into your state, you need to create the resource as code first. Let's import an existing repository as an example.

Once you finished writing the code, you can run the command .

Run terraform import

Note: The current implementation of can only import resources into the state. It does not generate configuration. A future version of Terraform will also generate configuration.

The above import is considered a "simple import": one resource is imported into the state file. An import may also result in a "complex import" where multiple resources are imported. For example, a repository most like also has a branch protection rule associated with it.

In this scenario, the secondary resources will not already exist in the configuration, so it is necessary to consult the import output and create a resource block in the configuration for each secondary resource. If this is not done, Terraform will plan to destroy the imported objects on the next run.

If you want to rename or otherwise move the imported resources, you should give the state management commands a try.

Conclusion

In this article, you learned how to manage your GitHub infrastructure as code. You also learned how to keep your code DRY with Terraform modules. Also, you can find the final example on GitHub. Feel free to fork this repository and use it as a starting point for your own organization.

In the next part of this series, you will learn how to automate the terraform and commands inside your CI and how to deploy changes following the GitHub flow.

Article last updated: 08/10/2021

Sours: https://www.mineiros.io/blog/how-to-manage-your-github-organization-with-terraform/
Demo: Terraform Cloud + Github VCS

terraform-github-repository

Build StatusGitHub tag (latest SemVer)Terraform VersionGithub Provider VersionJoin Slack

A Terraform module for creating a public or private repository on Github.

This module supports Terraform v1.x and is compatible with the Official Terraform GitHub Provider v4.10 and above from .

Attention: This module is incompatible with the Hashicorp GitHub Provider! The latest version of this module supporting provider is

Security related notice: Versions 4.7.0, 4.8.0, 4.9.0 and 4.9.1 of the Terraform Github Provider are deny-listed in version constraints as a regression introduced in 4.7.0 and fixed in 4.9.2 creates public repositories from templates even if visibility is set to private.

Module Features

In contrast to the plain resource this module enables various other features like Branch Protection or Collaborator Management.

  • Default Security Settings: This module creates a repository by default, Deploy keys are by default

  • Standard Repository Features: Setting basic Metadata, Merge Strategy, Auto Init, License Template, Gitignore Template, Template Repository

  • Extended Repository Features: Branch Protection, Issue Labels, Handle Github Default Issue Labels, Collaborators, Teams, Deploy Keys, Projects, Repository Webhooks

  • Features not yet implemented: Project Columns support, Actions, Repository File

Getting Started

Most basic usage creating a new private github repository.

module"repository" { source ="mineiros-io/repository/github" version ="~> 0.10.0" name ="terraform-github-repository" license_template ="apache-2.0" gitignore_template ="Terraform" } provider"github" {} terraform { required_version ="~> 1.0"required_providers { github = { source ="integrations/github" version ="~> 4.0" } } }

Module Argument Reference

See variables.tf and examples/ for details and use-cases.

Top-level Arguments

Module Configuration

  • : (Optional )

    Due to the fact, that terraform does not offer on modules as of today (v0.12.24) we might hit race conditions when dealing with team names instead of ids. So when using the feature of adding teams by slug/name to the repository when creating it, make sure to add all teams to this list as indirect dependencies. Default is .

Repository Configuration

  • : (Required )

    The name of the repository.

  • : (Optional )

    A object of default settings to use instead of module defaults for top-level arguments. See below for a list of supported arguments. Default is - use module defaults as described in the README.

  • : (Optional )

    A object of settings to configure GitHub Pages in this repository. See below for a list of supported arguments. Default is .

  • : (Optional )

    Set to to disable merge commits on the repository. If you set this to you have to enable either or . Default is .

  • : (Optional )

    Set to to enable squash merges on the repository. Default is .

  • : (Optional )

    Set to to enable rebase merges on the repository. Default is .

  • : (Optional )

    A description of the repository. Default is .

  • : (Optional )

    Set to to disable the automatic deletion of head branches after pull requests are merged. Default is .

  • : (Optional )

    URL of a page describing the project. Default is .

  • : (Optional )

    DEPRECATED: Please use instead and update your code. parameter will be removed in a future version

  • : (Optional )

    Can be or . If your organization is associated with an enterprise account using GitHub Enterprise Cloud or GitHub Enterprise Server 2.20+, can also be . The parameter overrides the deprecated parameter. Default is . If the deprecated boolean parameter is used, the default value is adjusted to respect this setting.

  • : (Optional )

    Set to true to enable the GitHub Issues features on the repository. Default is

  • : (Optional )

    Set to true to enable the GitHub Projects features on the repository. Default is

  • : (Optional )

    Set to true to enable the GitHub Wiki features on the repository. Default is

  • : (Optional )

    Set to to enable the (deprecated) downloads features on the repository. Default is .

  • : (Optional )

    Set to to tell GitHub that this is a template repository. Default is .

  • : (Optional )

    The name of the default branch of the repository. NOTE: This can only be set after a repository has already been created, and after a correct reference has been created for the target branch inside the repository. This means a user will have to omit this parameter from the initial repository creation and create the target branch inside of the repository prior to setting this attribute. Default is .

  • : (Optional )

    Specifies if the repository should be archived. NOTE: Currently, the API does not support unarchiving. Default is .

  • : (Optional )

    The list of topics of the repository. Default is .

  • : (Optional )

    A list of additional topics of the repository. Those topics will be added to the list of . This is useful if are used and the list should be extended with more topics. Default is .

  • : (Optional )

    Set to to disable security alerts for vulnerable dependencies. Enabling requires alerts to be enabled on the owner level.

  • : (Optional )

    Set to to not archive the repository instead of deleting on destroy.

Repository Creation Configuration

The following four arguments can only be set at repository creation and changes will be ignored for repository updates and will not show a diff in plan or apply phase.

  • : (Optional )

    Set to to not produce an initial commit in the repository. Default is .

  • : (Optional )

    Use the name of the template without the extension. Default is

  • : (Optional )

    Use the name of the template without the extension. Default is

  • : (Optional )

    Use a template repository to create this resource. See Template Object Attributes below for details.

Teams Configuration

Your can use non-computed (known at ) team names or slugs ( Attributes) or computed (only known in phase) team IDs ( Attributes). When using non-computed names/slugs teams need to exist before running plan. This is due to some terraform limitation and we will update the module once terraform removed thislimitation.

  • or : (Optional )

    A list of teams to grant pull (read-only) permission. Recommended for non-code contributors who want to view or discuss your project. Default is .

  • or : (Optional )

    A list of teams to grant triage permission. Recommended for contributors who need to proactively manage issues and pull requests without write access. Default is .

  • or : (Optional )

    A list of teams to grant push (read-write) permission. Recommended for contributors who actively push to your project. Default is .

  • or : (Optional )

    A list of teams to grant maintain permission. Recommended for project managers who need to manage the repository without access to sensitive or destructive actions. Default is .

  • or : (Optional )

    A list of teams to grant admin (full) permission. Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository. Default is .

Collaborator Configuration

  • : (Optional )

    A list of user names to add as collaborators granting them pull (read-only) permission. Recommended for non-code contributors who want to view or discuss your project. Default is .

  • : (Optional )

    A list of user names to add as collaborators granting them triage permission. Recommended for contributors who need to proactively manage issues and pull requests without write access. Default is .

  • : (Optional )

    A list of user names to add as collaborators granting them push (read-write) permission. Recommended for contributors who actively push to your project. Default is .

  • : (Optional )

    A list of user names to add as collaborators granting them maintain permission. Recommended for project managers who need to manage the repository without access to sensitive or destructive actions. Default is .

  • : (Optional )

    A list of user names to add as collaborators granting them admin (full) permission. Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository. Default is .

Deploy Keys Configuration

  • : (Optional )

    Specifies deploy keys and access-level of deploy keys used in this repository. Every in the list will be converted internally into the representation with the argument being set to the . details are explained below. Default is .

  • : (Optional )

    Same as argument with the following differences: Use this argument if you depend on computed keys that terraform can not use in resource execution. Downside of this is the recreation of deploy key resources whenever the order in the list changes. Prefer whenever possible. This argument does not conflict with and should exclusively be used for computed resources. Default is .

Branch Protections Configuration

  • : (Optional )

    This resource allows you to configure branch protection for repositories in your organization. When applied, the branch will be protected from forced pushes and deletion. Additional constraints, such as required status checks or restrictions on users and teams, can also be configured. Default is unless is used.

  • : (DEPRECATED)

    DEPRECATED To ensure compatibility with future versions of this module, please use . This argument is ignored if is used. Default is .

Issue Labels Configuration

  • : (Optional )

    This resource allows you to create and manage issue labels within your GitHub organization. Issue labels are keyed off of their "name", so pre-existing issue labels result in a 422 HTTP error if they exist outside of Terraform. Normally this would not be an issue, except new repositories are created with a "default" set of labels, and those labels easily conflict with custom ones. This resource will first check if the label exists, and then issue an update, otherwise it will create. Default is .

  • : (Optional )

    Specify if github default labels will be handled by terraform. This should be decided on upon creation of the repository. If you later decide to disable this feature, github default labels will be destroyed if not replaced by labels set in argument. Default is .

  • : (Optional )

    Specify whether you want to force or suppress the creation of issues labels. Default is if is or is non-empty, otherwise default is .

Projects Configuration

  • : (Optional )

    This resource allows you to create and manage projects for GitHub repository. Default is .

Webhooks Configuration

  • : (Optional )

    This resource allows you to create and manage webhooks for repositories in your organization. When applied, a webhook will be created which specifies a URL to receive events and which events to receieve. Additional constraints, such as SSL verification, pre-shared secret and content type can also be configured Default is .

Secrets Configuration

  • : (Optional )

    This map allows you to create and manage secrets for repositories in your organization. Each element in the map is considered a secret to be managed, being the key map the secret name and the value the corresponding secret in plain text:

    When applied, a secret with the given key and value will be created in the repositories. The value of the secrets must be given in plain text, github provider is in charge of encrypting it. Attention: You might want to get secrets via a data source from a secure vault and not add them in plain text to your source files; so you do not commit plaintext secrets into the git repository managing your github account. Default is .

Object Attributes

This is a special argument to set various defaults to be reused for multiple repositories. The following top-level arguments can be set as defaults: , , , , , , , , , , , , , , , . Module defaults are used for all arguments that are not set in . Using top level arguments override defaults set by this argument. Default is .

Object Attributes

This block is used for configuring GitHub Pages for the repository. The following top-level arguments must be set to configure GitHub Pages for the repository:

  • : (Required )

    The repository branch used to publish the site's source files.

  • : (Optional )

    The repository directory from which the site publishes.

  • : (Optional )

    The custom domain for the repository. This can only be set after the repository has been created. Default is .

Object Attributes

  • : (Required )

    The GitHub organization or user the template repository is owned by.

  • : (Required )

    The name of the template repository.

Object Attributes

  • : (Required )

    The SSH public key.

  • : (Optional )

    A Title for the key. Default is the comment field of SSH public key if it is not empty else it defaults to .

  • : (Optional )

    Specifies the level of access for the key. Default is .

  • : (Optional )

    Specifies an ID which is used to prevent resource recreation when the order in the list of deploy keys changes. The ID must be unique between and . Default is .

Object Attributes

  • : (Required )

    The Git branch to protect.

  • : (Optional )

    Setting this to true enforces status checks for repository administrators. Default is .

  • : (Optional )

    Setting this to true requires all commits to be signed with GPG. Default is .

  • : (Optional )

    Enforce restrictions for required status checks. See Required Status Checks below for details. Default is .

  • : (Optional )

    Enforce restrictions for pull request reviews. See Required Pull Request Reviews below for details. Default is .

  • : (Optional )

    Enforce restrictions for the users and teams that may push to the branch - only available for organization-owned repositories. See Restrictions below for details. Default is .

Object Attributes
  • : (Optional )

    Require branches to be up to date before merging. Defaults is .

  • : (Optional )

    The list of status checks to require in order to merge into this branch. Default is - No status checks are required.

Object Attributes
  • : (Optional )

    Dismiss approved reviews automatically when a new commit is pushed. Default is .

  • : (Optional )

    The list of user logins with dismissal access Default is .

  • : (Optional )

    The list of team slugs with dismissal access. Always use slug of the team, not its name. Each team already has to have access to the repository. Default is .

  • : (Optional )

    Require an approved review in pull requests including files with a designated code owner. Defaults is .

  • : (Optional )

    Require x number of approvals to satisfy branch protection requirements. If this is specified it must be a number between 1-6. This requirement matches Github's API, see the upstream documentation for more information. Default is no approving reviews are required.

Object Attributes
  • : (Optional )

    The list of user logins with push access. Default is .

  • : (Optional )

    The list of team slugs with push access. Always use slug of the team, not its name. Each team already has to have access to the repository. Default is .

  • : (Optional )

    The list of app slugs with push access. Default is .

Object Attributes

  • : (Required )

    The name of the label.

  • : (Required )

    A 6 character hex code, without the leading #, identifying the color of the label.

  • : (Optional )

    A short description of the label. Default is .

  • : (Optional )

    Specifies an ID which is used to prevent resource recreation when the order in the list of issue labels changes. Default is .

Object Attributes

  • : (Required )

    The name of the project.

  • : (Optional )

    The body of the project. Default is .

  • : (Optional )

    Specifies an ID which is used to prevent resource recreation when the order in the list of projects changes. Default is .

Object Attributes

  • : (Required )

    A list of events which should trigger the webhook. See a list of available events.

  • : (Required )

    The URL to which the payloads will be delivered.

  • : (Optional )

    Indicate if the webhook should receive events. Defaults to .

  • : (Optional )

    The media type used to serialize the payloads. Supported values include and . The default is .

  • : (Optional )

    If provided, the will be used as the to generate the HMAC hex digest value in the header.

  • : (Optional )

    Determines whether the SSL certificate of the host for will be verified when delivering payloads. Supported values include (verification is performed) and (verification is not performed). The default is . We strongly recommend not setting this to as you are subject to man-in-the-middle and other attacks.

Module Attributes Reference

The following attributes are exported by the module:

  • All repository attributes as returned by the resource containing all arguments as specified above and the other attributes as specified below.

    • A string of the form "orgname/reponame".

    • URL to the repository on the web.

    • URL that can be provided to git clone to clone the repository via SSH.

    • URL that can be provided to git clone to clone the repository via HTTPS.

    • URL that can be provided to git clone to clone the repository anonymously via the git protocol.

  • A map of Collaborator objects keyed by the of the collaborator as returned by the resource.

  • A merged map of deploy key objects for the keys originally passed via and as returned by the resource keyed by the input of the key.

  • A map of Project objects keyed by the of the project as returned by the resource

External Documentation

Module Versioning

This Module follows the principles of Semantic Versioning (SemVer).

Given a version number , we increment the:

  1. version when we make incompatible changes,
  2. version when we add functionality in a backwards compatible manner, and
  3. version when we make backwards compatible bug fixes.

Backwards compatibility in and version

  • Backwards compatibility in versions is not guaranteed when is increased. (Initial development)
  • Backwards compatibility in versions is not guaranteed when is increased. (Pre-release)

About Mineiros

Mineiros is a DevOps as a Service company based in Berlin, Germany. We offer commercial support for all of our projects and encourage you to reach out if you have any questions or need help. Feel free to send us an email at [email protected] or join our Community Slack channel.

We can also help you with:

  • Terraform modules for all types of infrastructure such as VPCs, Docker clusters, databases, logging and monitoring, CI, etc.
  • Consulting & training on AWS, Terraform and DevOps

Reporting Issues

We use GitHub Issues to track community reported issues and missing features.

Contributing

Contributions are always encouraged and welcome! For the process of accepting changes, we use Pull Requests. If you'd like more information, please see our Contribution Guidelines.

Makefile Targets

This repository comes with a handy Makefile. Run to see details on each available target.

License

license

This module is licensed under the Apache License Version 2.0, January 2004. Please see LICENSE for full details.

Copyright © 2021 Mineiros GmbH

Sours: https://github.com/mineiros-io/terraform-github-repository

Repository terraform github

For a more up-to-date tutorial, watch the demo: Understanding the GitHub Provider for Terraform

Terraform is an open source tool for managing infrastructure as code. Earlier I authored a blog post on leveraging version-controlled infrastructure with Terraform, and Terraform continues to push the boundaries on the definition of "infrastructure". Terraform is able to manage almost anything with an API, including Consul, Nomad, and GitHub. This blog post showcases using Terraform to manage GitHub organizations, repositories, teams, and permissions.

»Why Terraform?

The use case for managing cloud resources with Terraform is fairly straightforward - codify, version, automate, audit, reuse, and release. Managing GitHub organizations, repositories, teams, and permissions with Terraform provides the same benefits. You have immediate insight and a complete view of all memberships, repositories, and permissions inside all of your GitHub organizations.

Imagine a new employee onboarding process in which the employee adds their GitHub account to a team inside a Terraform configuration and submits a Pull Request. The hiring manager verifies the changes and merges the Pull Request. On the next Terraform run, the changes propagate out to GitHub, granting the new permissions. Not only does this happens in complete visibility of the company, but it also ensures consistency. Instead of relying on a human to click around in GitHub's web interface, we rely on a machine to push out policy and access. Whether you are managing a massive enterprise with hundreds of GitHub users or implementing a consistent labeling scheme across your personal projects, Terraform is the right tool for the job.

»Provider Setup

In order for Terraform to communicate with GitHub's API, we need to configure the GitHub Terraform provider. A Terraform provider is an abstraction of an API. Just like APIs require authentication, so do Terraform providers. In this case, the GitHub Terraform provider requires a and . Here is a sample Terraform configuration:

The is a personal access token for your account. GitHub has excellent documentation on generating a personal access token. The is the human-friendly name of the organization. It is also possible to source these values from environment variables, but that is not discussed in this post. For this post, the token must have , , and permissions.

GitHub Enterprise users may also specify the option to point to their GitHub Enterprise installation. The default value points to the public GitHub.com.

»Create a Repository

Terraform can manage the creation and lifecycle of all your GitHub repositories. Terraform will not touch existing GitHub repositories, so it is safe to adopt gradually. Here is an example configuration to create a new repository named "example-repo". This repository will be created in the organization specified in the provider.

Next, run to see what changes Terraform plans to make on GitHub.

Now run to apply the changes. This will create a real repository on GitHub.

You can verify the operation was successful by visiting your organization on GitHub and searching for the repository named "example-repo".

Because Terraform's syntax is declarative, any changes to the configuration result in a computed changeset. To demonstrate this behavior, change the description of the repository in the Terraform configuration. When you run , Terraform will report the resource has changed. When you run , Terraform will update the description of the repository, but not the other attributes.

Once the resource is under management with Terraform, all its attributes are controlled by the configuration. As an exercise, edit the "description" field for the newly-created repository on GitHub.com, and run . Terraform will detect the discrepancy and make an API call to GitHub to force the description to match the value in the Terraform configuration. The Terraform configuration becomes the single source of truth and policy.

»Creating Teams

Terraform supports more than just the management of GitHub repositories - it can also create GitHub teams and manage the members of those teams. Here is a sample Terraform configuration for creating a team. We can include this code in the same file as we created the GitHub repository resource. Terraform will intelligently handle both resources in the same file.

Just like before, run and :

Terraform created a team named "example-team" in the organization. You can login to GitHub and verify the team was created successfully, but it will have no members.

Terraform GitHub Team Created

Terraform can add members to the team using the resource:

This will add the GitHub user with the username "mitchellh" to the team we just created. Instead of hardcoding the , we can use Terraform's interpolation syntax to reference the output from the previous resource. Internally, this builds a dependency graph and tells Terraform to create the team before it creates the team membership. Because our team already exists, the will fill in the . If the resources did not exist, that argument would be marked as .

Next apply the changes:

We can verify the team was created by looking in the GitHub web interface.

Terraform GitHub Member Added

»Adding Teams to Repositories

Thus far, we have created a GitHub repository, GitHub team, and added a member to that GitHub team. To bring the journey full-circle, we can grant the team permission on the newly-created repository using the Terraform resource.

Just as before, run and .

Now members of the team "example-team" have push and pull access to the "example-repo" repository.

»Bonus: Setting Repository Labels

Many organizations have a common set of repository labels they like to apply to all projects. This helps ensure consistency and parity across projects. These labels may tie into internal systems that measure issue progress or metrics. In the past, managing these labels across repository has been a manual process or involved building a tool using the GitHub API. The challenge with both of these approaches is that they require the user to think about idempotency, change, and rollout effect. With Terraform, it is easy to manage issue labels and colors across all GitHub repositories. Even better, these labels are managed declaratively in Terraform configuration, so any changes are visible to the organization. This example also showcases a more advanced use of utilizing maps and lookups to build a more dynamic Terraform configuration.

First, create a map of the project label name to the hex color code. Remember that labels are case-sensitive, and the color code should not include the leading "#" character.

Next, use this variable with the resource in the Terraform configuration:

»Conclusion

Terraform is a powerful tool for codifying your organization's services. Whether you are provisioning instances on Amazon EC2, configuring monitoring with Datadog, or managing your GitHub teams and permissions, Terraform's declarative syntax can assist in managing the complexity of modern computing.

Sours: https://www.hashicorp.com/blog/managing-github-with-terraform
Terraform Cloud Integration for CI/CD with Github Repository

When I went out, I saw that a completely naked man was lying in my bed. He imposingly spread his legs and his intimate place was covered by a neat black hat, and his hands were folded. Behind his head.

You will also like:

Can. - looking upwards. Let's go to bed. We moved to the bed.



11399 11400 11401 11402 11403