terraform-provider-github VS terramate

There's an open feature request issue for it in the provider. I'd keep your eyes on 1534 for it to be implemented, as well as give it the 'ol thumbs-up bump.

I wanted to configure GitHub Pages using terraform because this project already uses it to configure this repository. But currently, due to how GitHub provider for terraform is written, configuring Pages requires some fiddling and will not work on the first run. During my research into how I could achieve declarative configuration for Pages, I found out that GitHub recently added actions that allow deploying to Pages without additional branch. I like this new approach better and in the future I will switch to it, but for now I decided to configure Pages manually as suggested by GitHub Pages Action that we are using.

Someone hit the wrong switch at the factory: https://github.com/integrations/terraform-provider-github/releases/tag/v4.28.0

Well, there are a lot of open issues [0] with no outlook to get them ever closed.

We've had issues with branch protection rules (the same code works with old actors in the state, but new actors erroring out without any reason), organization secrets, etc.

[0]: https://github.com/integrations/terraform-provider-github/is...

https://github.com/integrations/terraform-provider-github/is...

I don't understand how this hasn't gotten more attention throughout the years. I would like to learn about why that is.

I am a big fan of Squash and Merge but it's saddening that users have to configure that by hand on a repo when they first merge a commit via the GitHub UI, as many people aren't aware or don't think about it which can lead to nasty commit histories.

Am I missing something? Am I git'ing wrong?

Terramate: It seems like a good alternative, and I think it could have been a better choice for certain issues we had. With Terramate the transition from Terraform might have been easier since Terraform projects can be imported seamlessly. Furthermore, we don't have to think right away about how to modularize everything. The reason it was not chosen, is that my team was mainly familiar with Terragrunt. We had no experience with Terramate, so we decided to play it safely.

initContainers: - args: - >- curl -L https://github.com/terramate-io/terramate/releases/download/v${TERRAMATE_VERSION}/terramate_${TERRAMATE_VERSION}_linux_x86_64.tar.gz | tar xz command: - sh - -c env: - name: TERRAMATE_VERSION value: 0.4.5 image: curlimages/curl name: get-terramate volumeMounts: - mountPath: /home/curl_user/ name: terramate workingDir: /home/curl_user/ extraVolumes: - name: terramate emptyDir: {} extraVolumeMounts: - name: terramate mountPath: /usr/local/bin/terramate subPath: terramate readOnly: true

‍Terramate is an open-source IaC orchestration tool for Terraform, OpenTofu, Pulumi, Cloudformation, and others, that streamlines and scales your IaC workflows.

Nice, this looks close to https://terramate.io/ stacks

You might want to take a look at Terramate. Compared to other tooling such as Terragrunt we're not a wrapper that will lock you in yet another syntax. Terramate is a code generator and orchestrator that helps you to generate native Terraform that can be executed in whatever environment of your choice.

Another option for Terragrunt could be Terramate. It comes with Code Generation that helps you to automatically generate files such as Terraform, Provider and Backend configurations in various stacks (directories). The upside is that it always generates native Terraform code.

This can be done with a tool such as Terramate or Terragrunt (afaik Terragrunt doesn't come with change detection).

I'd love to add Terramate to the list of alternatives to Terraform Cloud!