Deprecate the project-id input in google/auth action.

[reakaleek]

The project-id is actually not relevant and is not used by the internal google-github-actions/auth action if the workload_identity_provider input is provided.

This option may be removed in a future release.

[v1v]

I'm a bit confused, I can see https://github.com/google-github-actions/auth#usage

Does it mean the usage example is not correct? Can you elaborate this please?

[reakaleek]

I'm a bit confused, I can see https://github.com/google-github-actions/auth#usage

Does it mean the usage example is not correct? Can you elaborate this please?

I actually had the same assumption and I think this is the reason why I added both inputs originially.

But if you look at our current usages. e.g.

• https://github.com/elastic/apm-agent-php/blob/1996e43e1e3fbd5ec6f35f2b88561eb2596f04cf/.github/workflows/release.yml#L70
• or https://github.com/elastic/elastic-otel-php/blob/8e0d448249591a9b503c576231022a5f305b449e/.github/workflows/release.yml#L69

we are not using the project-id. The default value of project-id is elastic-observability, which would actually be wrong in those cases.

I think, when the input workload_identity_provider is provided, it infers the project ID from the resource path.

[reakaleek]

IMO, for a future release,

maybe we can create a mapping of aliases to make it more readable

const aliases = {
  'elastic-observability': '1234',
  'elastic-observability-ci': '5678',
  'elastic-cdn': '91011'
}

so that the usage becomes something like this

      - uses: elastic/oblt-actions/google/[email protected]
        with:
          alias: 'elastic-observability'

[v1v]

I think, when the input workload_identity_provider is provided, it infers the project ID from the resource path.

Shall we raise a GH issue to the upstream project?

[reakaleek]

I think, when the input workload_identity_provider is provided, it infers the project ID from the resource path.

Shall we raise a GH issue to the upstream project?

From my understand setting the project ID still has a use

https://github.com/google-github-actions/auth/blob/c8788cc4c52eba6566baf085281fec298f1a1146/src/main.ts#L203

CLI tools or actions after the auth action benefit from the exported environment variables.

In our case it seems like it worked regardless.

[v1v]

I think, when the input workload_identity_provider is provided, it infers the project ID from the resource path.

I still need clarification. https://github.com/google-github-actions/auth/blob/c8788cc4c52eba6566baf085281fec298f1a1146/src/utils.ts#L67-L91 is the function to get the projectID, and the project_id input has higher precedence than credentials_json and service_account. It does nothing about workload_identity_provider.

I don't understand how workload_identity_provider infers the project-id and why we don' need project-id :/

[reakaleek]

I think, when the input workload_identity_provider is provided, it infers the project ID from the resource path.

I still need clarification. https://github.com/google-github-actions/auth/blob/c8788cc4c52eba6566baf085281fec298f1a1146/src/utils.ts#L67-L91 is the function to get the projectID, and the project_id input has higher precedence than credentials_json and service_account. It does nothing about workload_identity_provider.

I don't understand how workload_identity_provider infers the project-id and why we don' need project-id :/

The workload_identity_provider path includes the project number.

[v1v]

The workload_identity_provider path includes the project number.

Correct me if I'm wrong, so I think if it's not honoured then we might need to report that to the upstream, otherwise, I cannot understand what's the reason for letting using it while it's not honoured.

[reakaleek]

The workload_identity_provider path includes the project number.

Correct me if I'm wrong, so I think if it's not honoured then we might need to report that to the upstream, otherwise, I cannot understand what's the reason for letting using it while it's not honoured.

According to the README.md, project_id is not required to achieve Workload Identity Federation.

https://github.com/google-github-actions/auth?tab=readme-ov-file#inputs-workload-identity-federation

The only required attribute is workload_identity_provider.

P.S.

I can still ask, but from my understanding, it's a convenience option to export the project ID as an environment variable for other Google-related actions or tools.

[v1v]

I can still ask, but from my understanding, it's a convenience option to export the project ID as an environment variable for other Google-related actions or tools.

But if they don't match, will the exported variable be project_id rather than the project-id in workload_identity_provider?

In my view, it's not clear why https://github.com/google-github-actions/auth#usage shows a project_id.

[reakaleek]

I can still ask, but from my understanding, it's a convenience option to export the project ID as an environment variable for other Google-related actions or tools.

But if they don't match, will the exported variable be project_id rather than the project-id in workload_identity_provider?

In my view, it's not clear why https://github.com/google-github-actions/auth#usage shows a project_id.

Fair enough. Sorry, for being stubborn. I will create an issue shortly.. but what does it mean for this PR?

[v1v]

Fair enough. Sorry, for being stubborn. I will create an issue shortly.. but what does it mean for this PR?

No worries at all.

Let me review it now

[reakaleek]

Fair enough. Sorry, for being stubborn. I will create an issue shortly.. but what does it mean for this PR?

No worries at all.

Let me review it now

google-github-actions/auth#442

[v1v]

I see something interesting here:

I wonder if we need to keep this as deprecated in this case