Add new integrations registered to the same GitHub account whenever your workflow requires it.

Example use case

GitHub users rejoice: a feature that many have been asking for has been released – it is now possible to add multiple integrations registered for the same GitHub account! This means, for example, that you can work on repositories from one GitHub account in two different workspaces.

You can add a new integration in the Integrations tab, or when adding a new project by clicking on the + under GitHub:

![](/blog/images/github-multiple-integrations/github-multiple-integrations-1.png)

If you already have an integration connected to the GitHub account to which you've signed, a box with a warning will appear.

<Hint type="danger">

Make sure to read the warning and check your existing integrations before proceeding as any change to the permission settings affects ALL connected integrations.

</Hint>

![](/blog/images/github-multiple-integrations/github-multiple-integrations-2.png)

In other words, if you change the settings of the Buddy App on GitHub, it will update all workspaces and projects in Buddy connected to your GitHub account.

## Example use case

Let's assume you belong to a workspace in which you collaborate with other developers on selected projects hosted in your GitHub account. You decide to create another workspace for your private projects hosted in the same GitHub account. Next, you add a new integration in the workspace and give Buddy access to your private repositories.

<Hint type="danger">

At this moment, you provide access to these repositories in the other workspace integrated with this GitHub account. Make sure to bear this in mind!

</Hint>

<Hint type="info">

This also concerns existing integrations in which you update the permissions settings.

</Hint>

New feature: Multiple GitHub integrations support

Manage your infrastructure in Buddy using our new Terraform action

Terraform and Continuous Delivery

Terraform configuration and state

Terraform in Buddy

Example use

With its simple syntax, Terraform allows you to easily provision, change, and version resources in every cloud. Becoming one of the most popular IaC (Infrastructure as Code) tools out there, it is no wonder it quickly became one of the most requested features for Buddy. Well - it's finally here. 

## Terraform and Continuous Delivery 

Besides deploying the code, Terraform allows users to automate infrastructural changes. Terraform config is kept in the repository, making it possible to version. The delivery pipeline will automatically run 'terraform apply', adjusting our infrastructure to the requirements included in the code.

## Terraform configuration and state 

The infrastructure is described in Terraform configuration files (.tf). Running 'terraform apply' for the first time, will create the resources described. Apart from that, it will create something called **Terraform state** which will serve as a database for consecutive runs. 

Terraform state is crucial to the entire process as it lets us know what we have to do in the following 'terraform apply' executions. 

**Example:** 

1. In our configuration file, we state that a single 'EC2 t3.medium' instance will be required
2. First execution will create the Virtual Machine (as the state is empty) and will save its ID to the Terraform State
3. Another run will check our Terraform State and, seeing that the VM is already included, will not execute anything. Without the Terraform State, the VM would be created on every single execution

<Hint type="warning">

**IMPORTANT:** Please make sure that Terraform State is persistent. Without it, Terraform will create a new infrastructure with every consecutive run instead of updating the already existing one!

</Hint> 

To maintain your state, it is recommended to use something called [Terraform Backends](https://www.terraform.io/language/settings/backends/configuration). We recommend using AWS S3 or Google GCS

## Terraform in Buddy

You can use **Terraform CLI** action in our delivery pipelines. This action allows you to provide commands that will be executed in the context of the repository containing the '.tf' file. It also allows you to select the Terraform version. 

![](/blog/images/terraform-cli/terraform-cli-1.png)


<Hint type="info">

We recommend using a fixed Terraform version instead of the "latest". There were cases in the past where Terraform states varied between versions which caused issues. Using a fixed version gives you more control and prevents errors when changing or updating.

</Hint>

Terraform backend configuration can be done directly in the the '.tf' file in the repository, or by using the environment variables set in the **Variables** tab of the action. On top of this, Buddy provides dedicated AWS and GCP integration which allows for further backend configuration options in S3/DynamoDB and Google Cloud Storage.

![](/blog/images/terraform-cli/terraform-cli-2.png)

## Example use

![](/blog/images/terraform-cli/terraform-cli-3.png)

The pipeline above is one of the examples of how Terraform can be used. After the application is built, Terraform will validate if the configuration files are correct. If everything checks out, the following Terraform action will plan changes that will be executed after the manual approval. In this scenario we have used Rsync as our deployment action as an example.

![](/blog/images/terraform-cli/terraform-cli-4.png)

To ensure that the infrastructure changes trigger only when there are changes to the '*tif' file, we have added a trigger condition to actions 2-6. That way, whenever there are no infrastructural changes, the pipeline will build and deploy your app normally.

<Hint type="info">

Useful links:
 
- [Trigger Conditions](https://buddy.works/docs/pipelines/conditional-executions)
- [AWS integration](https://buddy.works/docs/integrations/amazon-web-services)
- [GCP integration](https://buddy.works/docs/integrations/google-cloud)

</Hint>

New action: Terraform CLI

Browse, add, compare, and manage Git tags in the latest addition to Buddy's source overlay

What you need to know

As Buddy, our mission is to make DevOps accessible to everyone by dragging it out of the terminal window. This also includes version control, the first step towards introducing automation to software development. Without version control, there would be no pipelines to take off the burden of manually [building](/docs/quickstart) and [deploying](/docs/deployments) your websites and applications.

Putting the words into practice: our service spreads a visual interface over Git, allowing you to browse and run Git operations in your repositories. This week we expand the UI with a new element – tags.

## What you need to know

You can find the tags in the Code tab:

![](/blog/images/tags-source/tags-source-1.png)

The scope of activities to perform depends on the type of repository in the project. If you are using an external provider like GitHub or Bitbucket, you can:

- view the complete list of tags in the project
- jump to the tagged commit in the repository
- compare the tag with other tags, branches, and commits
- download the repository in the tagged revision

![](/blog/images/tags-source/tags-source-2.png)

If you host your code on Buddy (a common practice for [on-premises installations](/docs/on-premises/introduction)), you can also create tags and apply them to commits in the repository. This can be done from dropdown menus across the whole service – for example, on the currently viewed commit:

![](/blog/images/tags-source/tags-source-3.png)

<Hint type="info">

You can also remove tags from the same dropdown menus in Buddy-hosted repositories.

</Hint>

<Hint type="warning">

Buddy is 100% customer-driven. Let us know what integrations you need to take your automation game to the next level! If there’s a feature or integration you miss, talk to us on the live chat or drop us a line at <support@buddy.works>.

</Hint>

New feature: Tags in Code

Assign team leaders to individual projects with the new default permissions role.

Adding Project Managers to projects

Project Managers vs Custom roles

What's next

Until now, only the workspace administrator could manage users in the project. This has changed with this week's release in which we added a new permission role: the **Project Manager**.

A person with the Project Manager role has full access to the project's source code, pipelines, and sandboxes. They are also entitled to perform the following actions:

- add and remove groups and users from the project
- invite new people directly to the project
- change the roles of the users in the project

<Hint type="tip">

The role can also be assigned to groups, immediately updating the permission scope of multiple users at once.

</Hint>

## Adding Project Managers to projects

To add a person with PM rights to the project, go to the Team tab and click Add people. Look up the person that you want to add, select the role in the right column, and click the button to confirm:

![](/blog/images/roles-project-manager/roles-project-manager-1.png)

<Hint type="tip">

You can also update the role of existing users in the project.

</Hint>

## Project Managers vs Custom roles

<Hint type="info">

A Project Manager can assign any role in the project to the project member, including customized. However, only workspace admins can *define* custom roles.

</Hint>

To add a custom role, go to People → Roles tab from the system dashboard and click the plus button at the bottom:

![](/blog/images/roles-project-manager/roles-project-manager-2.png)

Here you can set the access scope to each part (module) of the service: source, pipelines, and sandboxes. The Project Team module is by default set to view-only, which means you can only browse your team members.

![](/blog/images/roles-project-manager/roles-project-manager-3.png)

<Hint type="warning">

Please mind that changing the scope to 'Manage' will force the scope of all remaining modules to 'Manage', essentially changing the custom role into the default PM role.

</Hint>

## What's next

The next role that we're going to add will be the Group Manager. A person with this role will be able to add and remove users from their parent group, which also involves managing project access if the group is assigned to a project.

<Hint type="info">

If you're interested in how Buddy facilitates user management, check out our articles on [SSO authentication](/docs/account/sso/saml-sso) and [managing groups in projects](/blog/group-management-update).

</Hint>

New role: Project Manager

Deploy containers to AWS App Runner and check the status of the application with two new additions to the Amazon action roster.

Configuration

The App Runner is the newest addition to the Amazon services that can be automated by Buddy. Delivered in response to popular demand, the feature is broken into two actions:

- **App Runner Deploy** – lets you deploy containerized web applications and API's to AWS.
- **App Runner Monitor** – waits until `operation_in_progress` has finished and checks the status of the deployed application.

New action: AWS App Runner

Learn how we redesigned the build actions to accommodate new features and further improve the UX of our pipelines.

Run commands

Environment

Services

Caching

Variables

Conditions

Options

If you're a Buddy regular, you surely noticed that the service has been evolving not only in terms of added features, but the looks as well. The new, updated designs have been steadily taking over various parts of the UI. Their spoils so far include pipeline settings, integrations, permissions, sandboxes, variables, users and groups, branches and merge requests, SSH keys, and more.

Below you will find a summary of the latest changes to the second most popular type of actions after deployments: builds.

Buddy Blog

New feature: Multiple GitHub integrations support

New action: Terraform CLI

New feature: Tags in Code

New role: Project Manager

New action: AWS App Runner

🏗 Feature spotlight: New build actions