Hi, I have a weird behavior when I want to upgrad...
# package-authoring
Hi, I have a weird behavior when I want to upgrade the provider to our latest version of our TF provider. I’m executing upgrade provider script:
$ upgrade-provider ovh/pulumi-ovh
--- Set Up Environment ---
- GOWORK=off
--- done ---
The scripts found some missing mapping, ok not a problem, indeed, in TF provider side we removed a resources and two datasources. I edited the
file but when I’m executing the script again (and again), it sound that the changes are not seen, I stil have the issues even if I make the changes in resources.go file 😞 FYI the provider is the OVHcloud provider: https://github.com/ovh/pulumi-ovh Is it possible to help us in this blocking behavior? Thx
Hi Aurelie, does the error happen if you run
make tfgen
outside of
? Is there a branch I could try to repro this on?
My guess would be that something in upgrade-provider is managing branching in a way that wipes out your local edits to provider/resources.go ; but if it's something else I'd be really curious to have a look, never seen this particular problem before of edits to provider/resources.go not being repected.
make tfgen
fails because the new version of resources.go does not match with the current version of the TF provider
I created a fresh new devpod environment , re executed upgrade provider tool and now it’s working. The PR have been created.
but ... the GH action fails
Hi @thankful-match-46035, I suspect you have a toolchain directive in your
file. Not all tools work well with that and I believe you can just remove that line from
. LMK if that works!
after fixing the go verson in th Gh action it worked
Almost every upgrade provider is not smooth 😞 this time, the pulumi provider and bridge versions upgraded, with go 1.21, so I needed to update the go version in several files in my repository.
Really appreciate this feedback, it resonates, we're still very far from a hassle-free experience on these upgrades.
Can we capture any of these recent round of issues into tickets? Sounds like there was a problem with the toolchain directive and Go versions, and the other problem was with the workflow of 1. edit resources.go 2. run upgrade-provider 3. hit tfgen errors 4. go to step 1 where it would not pick up the errors?
I've the suspicion that a (half-way) smooth upgrade of a provider including an upgrade of GO requires https://github.com/pulumi/ci-mgmt. Or at least some features of it, that must run in the provider repo.
Do you think of something in particular for this case, like ci-mgmt controlling the pinned version of the environment (Go version)?
Exactly, because
is responsible, or designed for, managing upgrades to the build infrastructure like the Makefile or the GH Workflows.
Could we factor out the setup of dependencies so we version it separately? This is always a little tricky since there's no one-size-fits-all tooling. We currently cannot adopt containers for this because some of the larger providers struggle with a container overhead. The GitHub Action native way seems to be
actions. We could go that route, and somehow solve for keeping the dependency-set consistent across this new action, devbox.json for local, and maybe publish a container as well for folks that prefer containerized build or dev.
We critically depend on ci-mgmt for internal operations right now and it's a bit too unwieldy to reuse for community, but if we find ways to carve out functionality into well-defined blocks I can see us evolving ci-mgmt to become simpler by reusing those blocks while still remaining operational.
I just filed https://github.com/pulumi/upgrade-provider/issues/257 this is something I can reproduce that definitely feels very off, I think this might have been responsible for wiping the source changes
However I am finding that the default settings wipe out any changes, and checkout
, including wiping out any local changes to
compared to
@enough-garden-22763 OUCH! 😮🔥