You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a repository using terraform resource "github_repository" "this" {}, there is a param available template { owner = "github"; repository = "terraform-template-module"; include_all_branches = true } which allows the repo to pull the template and apply it as the repository initial commit.
However, when using the GitHub Apps framework in the provider authentication, the provider creates an Installation Access Token (IAT) which can only ever get resources from a single organization. If the Template is not in the same organization as the target organization for the new repository, the apply fails with a 404 error.
Potential solutions:
Recommended: Split the template parameter to its own resource and allow the github_repository resource to consume that resource as an input. This would allow a user to provide a different provider alias to the template repository resource if necessary.
Not Recommended: Allow a single provider to mint multiple IATs for multiple organizations and choose which IAT to leverage based on the resource names. Would require that users specify the owner on every resource, which may require refactoring additional resources.
Enterprise Only: Change the GitHub APIs to allow IATs to consume Internal template repositories from any organization within the Enterprise. Seems like a potentially reasonable change, but outside the scope of the Terraform provider.
For now, my workaround is to fork the template repositories into the organizations that need them, which is less than ideal but still allows for some level of tracking.
Additionally, if the resource could fail earlier by actually attempting to read the template repository during the plan, it would help developers. This could be treated as a minor bugfix item, and might be better to split it out of the feature request.
SDK Version
No response
API Version
No response
Relevant log output
Error: POST https://api.github.com/repos/my-organization/terraform-template-repository/generate: 404 Not Found []
with module.this.module.this["instance"].github_repository.repository
on .terraform/modules/this.this/main.tf line 99, in resource "github_repository""repository":
`resource "github_repository""repository" {`
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Describe the need
Hello,
When creating a repository using terraform
resource "github_repository" "this" {}
, there is a param availabletemplate { owner = "github"; repository = "terraform-template-module"; include_all_branches = true }
which allows the repo to pull the template and apply it as the repository initial commit.However, when using the GitHub Apps framework in the provider authentication, the provider creates an Installation Access Token (IAT) which can only ever get resources from a single organization. If the Template is not in the same organization as the target organization for the new repository, the apply fails with a 404 error.
Potential solutions:
template
parameter to its own resource and allow thegithub_repository
resource to consume that resource as an input. This would allow a user to provide a different provider alias to the template repository resource if necessary.owner
on every resource, which may require refactoring additionalresource
s.For now, my workaround is to fork the template repositories into the organizations that need them, which is less than ideal but still allows for some level of tracking.
Additionally, if the resource could fail earlier by actually attempting to read the template repository during the plan, it would help developers. This could be treated as a minor bugfix item, and might be better to split it out of the feature request.
SDK Version
No response
API Version
No response
Relevant log output
Code of Conduct
The text was updated successfully, but these errors were encountered: