Consider accepting major version as input param

[t0yv0]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

The heuristics here are interesting but relatively unexpected:

Major Versions

When we're wanting to build for a different major version from the last release, we can do this using three methods:

Use a version branch containing just the major version number e.g. (v1 or v7). Pushing to this branch, or opening a pull request with this branch as the "base" will use this major version.
Name the branch with prefix upgrade- and suffix -major (e.g. upgrade-aws-to-v2.0.0-major). This will cause the version number to be incremented by a major increment instead of a minor increment.
Add the label needs-release/major to a pull request. This will cause the version number to be incremented by a major increment instead of a minor increment.

Consider letting the user just say something akin to:

      - uses: pulumi/provider-version-action@v1
        id: provider-version
        with:
          set-env: "PROVIDER_VERSION"
          major-version: 3

Affected area/feature

[flostadler]

Another reason to consider accepting this as an input param is that GitHub seems to cache the action context based on the commit sha.

I tried adding the needs-release/major and switching the base branch to v3 for an existing PR in pulumi-eks and it still kept resolving to the old version because the context didn't get updated.

The only way to force update it was git commit --no-edit --amend & git push --force to trigger a fresh run

[danielrbradley]

Major version argument sounds good - certainly easier to reason about 👍