[FEAT]: Data source to resolve the current repository from the Actions environment

[jacobkretz-bf]

Describe the need

When Terraform runs inside a GitHub Actions workflow, the runner already exposes the current repository via GITHUB_REPOSITORY (owner/repo), and the provider already sources owner/token from the environment (GITHUB_OWNER, GITHUB_TOKEN). However, there is no way to reference the repository the workflow is running in without declaring an input variable and wiring TF_VAR_repository: ${{ github.event.repository.name }} in the workflow.

Today the only env-only (no-variable) workaround is an external data source shelling out to read $GITHUB_REPOSITORY + jq, which is brittle. It would be valuable for the provider to resolve the current repository directly from the environment, mirroring how the provider already resolves owner.

Note that the existing github_repository data source requires name or full_name and errors otherwise ("one of full_name or name has to be provided"), so there is no env fallback available today.

Possible approaches (deferring the final shape to maintainers):

1. Extend github_repository — make name/full_name optional and, when both are omitted, fall back to GITHUB_REPOSITORY. Smallest surface-area change; reuses the existing data source.

   data "github_repository" "current" {} # name/full_name omitted -> $GITHUB_REPOSITORY

2. New dedicated github_repository_current data source — no required inputs; resolves the current repo from GITHUB_REPOSITORY and exposes the same attributes as github_repository. Clearest intent, explicit and discoverable.

   data "github_repository_current" "this" {}
   output "name" { value = data.github_repository_current.this.name }

3. New broader github_context data source — exposes Actions context (repository, owner, ref, sha, ...) from the runner env, of which repository is one field.

   data "github_context" "this" {}
   output "repo" { value = data.github_context.this.repository }

Recommendation: option 1 (extend the existing data source) is the least invasive, with option 2 (github_repository_current) as a clean explicit alternative if maintainers prefer not to overload github_repository.

GitHub Installation Type

• GitHub.com (Free, Pro, or Team)

Relevant log output

None.

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

👋 Hi, and thank you for opening this issue!

This repo is maintained by GitHub and community members on a best-effort basis. We'll get to this as soon as we can.

You can help us prioritize by adding details, reproduction steps, or a 👍 to issues that matter to you, and by joining the discussion on open issues and PRs.

---

_{🤖 This is an automated message.}

[deiga]

I don't think this is something we want to support. We're working to make the provider require more explicit configuration.

These "magic" defaults and environment variables end up causing more trouble for users and maintainers.

As you showed this is already possible fairly simply with tfvars.

[jacobkretz-bf]

The data source at least provides the optionality though. A new data source would make usage explicit so there isn't "magic" in a sense as the user is choosing this. tfvars requires a lot of supporting infrastructure, because you have to explicitly set it, so it requires an "external" system to do that. A new data source would enable the dropping of variable, and have the terrform read it from the environment. I look at it as something similar to AWS aws_region data source. You can specify region on the provider but as soon as you do that you're lock to a region. The data source opens up things like reusable modules across regions.

In our specific use case we write several repo attributes as tags to our AWS resources. We deploy via GitHub actions, so it just seems "variable" overhead when we're already "in" the environment to have to tell the TF your in this environment. I don't know if that makes sense.