fix: remove deprecation

[v1v]

Closes #384

What

Remove deprecation and clarify when and how to use it.

Why

Consumers can run subsequent gcloud commands after using this Github Action, and those gcloud commands will use the default value, even if the project-number points to a different Google Project.

That's problematic and hard to debug, therefore let's ensure we remove the deprecation.

Further details

See

[Copilot]

Pull Request Overview

This PR removes the deprecation warning from the project-id input parameter in the google/auth action. The deprecation message incorrectly stated that project-id was not relevant, but it is actually required by downstream authentication systems like the gcloud CLI.

Key changes:

• Removed the deprecation message from project-id input
• Updated the input description to clarify when project-id is needed
• Enhanced documentation with a new usage example demonstrating gcloud CLI integration

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
google/auth/action.yml	Removed deprecation message and updated project-id description to clarify its optional but potentially required nature
google/auth/README.md	Updated documentation table formatting, expanded usage examples to include gcloud CLI scenario demonstrating when project-id is needed

Comments suppressed due to low confidence (1)

google/auth/README.md:1

• The job name 'job_id' has been changed to 'federation'. Ensure this change is intentional and consider updating any references to this job name in dependent workflows or documentation.

# <!--name-->google/auth<!--/name-->

[fr4nc1sc0-r4m0n]

For me it's a little bit weird to have two input parameters for the same purpose. Maybe we can infer one from the other.
What do you think?

[v1v]

That's tricky:

• Deprecate the project-id input in google/auth action. #124 (comment)

It will require the workload identity to have a specific permission, so we can run some API to gather the project name for the given project number.

It's not ideal, but there is no way to do it smoothly, since this is a public repository I prefer we do not make a breaking change here.

We could provide something for a breaking change in the future, we track those requests in #126

[v1v]

I updated the description with the context for clarity.

---

We faced some issues recently in one GH workflow using gcloud for something else and was actually failing. I'll pin gyou there

[fr4nc1sc0-r4m0n]

Thanks for the information @v1v. I understand the problem.
Maybe creating the key-value map that @reakaleek was proposing could be a good approach. At least, this is static data so easy to maintain and we would be avoiding that the user adds contradictory input data.

[v1v]

In my opinion, this constitutes a breaking change. If we decide to move forward, we'll need to plan for v2, which isn’t currently on our roadmap for the near future. Would you mind creating a GitHub issue to propose this change?

This change simply involves removing the deprecation and guiding consumers on how to properly use it.

[fr4nc1sc0-r4m0n]

Would you mind creating a GitHub issue to propose this change?

Sure.

In my opinion, this constitutes a breaking change.

I think it could be a breaking change or not depending if we remove one of the input args; but maintaining both and giving preference (and documenting it of course) to one over another (similar as we were doing with the deprecation warning) could be a way to solve that in the v1 IMHO.
For instance:

• Preference to project-id over project-number .
  • If you set project-id and project-number as input args ---> we don't care about the project-number and get the project-number from the id-number map
  • If you only set project-id as input arg ---> we get the project-number from the id-number map
  • If you only set the project-number as input arg ---> we get the project-id from the number-id map

or vice versa. What do you think?

[fr4nc1sc0-r4m0n]

LGTM