Highly unexpected default behavior of pulling origin/main

[t0yv0]

What happened?

As user attempting to work with upgrade-provider CLI interactively, I expect to be able to edit code and checkout different branches of the project and re-run upgrade-provider to try to perform an upgrade from the current state of the folder to some new desired state. This especially relevant when iterating on a failed upgrade-provider run.

However I am finding that the default settings wipe out any changes, and checkout main, including wiping out any local changes to main compared to origin/main.

  - Pull Default Branch
    - git: /usr/bin/git ls-remote --heads origin
    - Find default Branch: main
    - git: /usr/bin/git fetch
    - git: /usr/bin/git checkout main
    - git: /usr/bin/git pull origin

This interaction with git fetch should be under a flag I think and not the default behavior.

Example

$ git rev-parse HEAD                                                                                                                                                 16b04fcc58b2194416fa6d52faeb986dbdc6de29

~/code/upgrade-provider/upgrade-provider emailbob/pulumi-twingate --upstream-provider-name terraform-provider-twingate --upstream-provider-org Twingate --target-version v1.2.1

upgrade-provider version: 6c445682384d34091cdda3f616956d44d3254879

This invocation fails with go 1.17 issues in sdk/go.mod, however fixing that and trying again fails again which is highly confusing.

Another issue was reported about https://github.com/ovh/pulumi-ovh where tfgen was failing with token mapping issues, and the maintainer was trying to edit resources.go and retry upgrade-provider run. I've not verified this in depth but it could be stemming from the same issue of reverting to main.

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).

[guineveresaenger]

Can you describe the exact steps that produce this behavior? We upgrade against upstream/main on purpose, but any changes applied to the upgrade git branch (specifically to resources.go) should not get clobbered.

Are you expecting that other branches should be the ones being upgraded against as well, e.g.

1. git checkout feature-branch
2. in feature-branch, make changes, commit
3. from feature-branch, run upgrade-provider and create upgrade branch based on feature-branch

[t0yv0]

I'm just relaying the user confusion. This is not what the users expect it seems. I'd venture the expectation is that the tool takes the current worktree, possibly a dirty worktree where there are uncommitted changes, and performs an upgrade from there. When the upgrade fails, users expect to iterate on the configuration by editing resources.go and trying again. I think if the workflow above is how this needs to work and we do not want to change how the tool works, a little error messaging and guidance can go a long way, for example rejecting dirty worktree or responding with next steps to tfgen failures.

Even if we don't make any changes here it's good to have this filed up so we can direct users here for workarounds. Thanks a lot!

[guineveresaenger]

This makes sense - thank you!