https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# pulumiverse
s
This message was deleted.
l
@big-architect-71258 as an extension to the 
schema-tools
issue I'm working on, I have a related branch for reusable workflows which will make use of the patched schema-tools: https://github.com/pulumiverse/infra/tree/matrix-simplified Once this is fixed, I'll be testing it in a provider I maintain myself: https://github.com/pulumiverse/pulumi-unifi/tree/reuse-workflows before I will communicate to roll this out for the other providers.
🚀 1
b
@limited-rainbow-51650 This is awesome! But why is the problem I described, with referencing the dotnet version, not a real issue in the provider publishing process? I would have assumed that the wrong reference would break the GitHub workflow.
l
Can't answer this on the spot to be honest. There are so many variations these days on the workflows that I would need more time to investigate this individual case.
👍 1
b
@limited-rainbow-51650 Perhaps the publishing process of the MSSQL provider will now fail because I corrected the variable reference. We'll know if you approve the PR again, because my last push about the invalid reference reset your initial approval. Sorry BTW for this chaos: I should've noticed the issue with the invalid variable reference earlier.
@limited-rainbow-51650 The publishing process once again crashed, not because of something with the dotnet version variable reference but in the dreaded 
Check worktree clean
step. I took every precaution I know of, especially using the same Go Version locally to create the SDK and the provider, as within the pipeline. Can you help me here to figure out why 
tfgen
created a new 
schema.json
, what changed the Python SDK, what eventually stopped the pipeline. The publishing process is definitely something that makes me think to stop contributing. Sorry to say, but it's really frustrating. https://github.com/pulumiverse/pulumi-mssql/actions/runs/5199560930/jobs/9377293948
Oh and needless to say: before I create a new release, which triggers the publishing workflow, I issue 
make build_sdks
locally and check with 
git status
manually if the worktree stays clean.
Okay, I could reproduce the issue when I use an empty GO 1.20.4 Container and manually issue all steps of the build pipeline in it. But I simply can't spot the difference why my local dev environment doesn't change the worktree. Cleaning the GO environment didn't work: 
go clean -cache -modcache -fuzzcache
Okay, I had missing resource plugins. Locally those plugins where installed. But not in the empty build environment. When I clean my Pulumi environment, I now can reproduce the change of the worktree locally.
@limited-rainbow-51650 Would awesome if you could approve my (hopefully last) PR to fix the GitHub workflow for the MSSQL provider.
@limited-rainbow-51650 Thanks!!
youre welcome 1
@limited-rainbow-51650 it's seriously a constant struggle!!! ðŸĪŠ ðŸĪĶ🏞‍♂ïļ
@limited-rainbow-51650 I started a "checklist" for provider maintainers about what things need to be taken care of to end up with a successful publishing pipeline. Perhaps you can have a look and tell me if I missed something. https://github.com/tmeckel/pulumi-tf-provider-cookiecutter/issues/9
@limited-rainbow-51650 I'm a little embarrassed now, but could you approve the pull request again?
✅ 1
WAAAHHHHOOOO 😀 @limited-rainbow-51650 Many thanks for approving the bunch of PRs!
🎊 1
l
@big-architect-71258 all credit to you for persisting to get this working!! 🎉
â™Ĩïļ 1
b
@limited-rainbow-51650 By documenting the most prominent traps you can fall while publishing a provider I hope the next time I'll be much quicker. And of course I'll update my Cookiecutter template to reflect the last insights.
4 Views
Open in Slack
PreviousNext
Powered by