https://pulumi.com
Join Slack
Hi, I have a weird behavior when I want to upgrade the provider to our latest version of our TF pro...
# package-authoring
t
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
- PULUMI_MISSING_DOCS_ERROR=false
- PULUMI_EXTRA_MAPPING_ERROR=true
--- 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 
provider/resources.go
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
e
Hi Aurelie, does the error happen if you run 
make tfgen
outside of 
upgrade-provider
? 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.
t
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
a
Hi @thankful-match-46035, I suspect you have a toolchain directive in your 
go.mod
file. Not all tools work well with that and I believe you can just remove that line from 
go.mod
. LMK if that works!
t
after fixing the go verson in th Gh action it worked
🎉 1
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.
e
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?
b
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.
e
Do you think of something in particular for this case, like ci-mgmt controlling the pinned version of the environment (Go version)?
b
Exactly, because 
ci-mgmt
is responsible, or designed for, managing upgrades to the build infrastructure like the Makefile or the GH Workflows.
e
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 
setup-foo
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.
👍🏻 1
🚀 1
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
🚀 1
b
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
.
@enough-garden-22763 OUCH! 😮🔥
23 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by