search

pulumi / upgrade-provider

A tool to automate provider upgrades on your local machine
7 stars 1 forks source link

PR name collisions cancel prod jobs #200

Closed t0yv0 closed 1 year ago

t0yv0 commented 1 year ago

What happened?

See: https://github.com/pulumi/pulumi-azure/issues/1448

If the PR names (and branch names) used by the tool were unique, we wouldn't have this problem. As things stand, test jobs have cancelled out prod jobs for bridge update.

Example

N/A

Output of pulumi about

N/A

Additional context

N/A

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

iwahbe commented 1 year ago

It looks like the root cause is that --target-pulumi-version=08c4f69f96fcaedc4018bc516f72f0b4ec504736 doesn't make it into the name. I see two possible paths forward here:

  1. Ensure that SHA parameters are always wind up in the name.
  2. Ensure that CI driven builds always generate unique names by appending some random bit to them.

My instinct is that (2) will be the simplest and least breakable. We can add a --unique flag set by CI that appends, say, the last commit SHA to the branch name. This will preserve the local development experience, but improve the CI experience.

iwahbe commented 1 year ago

Or (3), we can punt to the user by adding a --branch-name flag and letting the running job choose.

t0yv0 commented 1 year ago

I like (2) will be the simplest and least breakable.

we can punt to the user by adding a --branch-name flag and letting the running job choose

We + platform team are the user. This requires further small but hard to test change through GHA wrappers. Do we have time for that?

iwahbe commented 1 year ago

We + platform team are the user. This requires further small but hard to test change through GHA wrappers. Do we have time for that?

I think so, but I still think that (2) will be best overall.