Embed sdk versions #68
Conversation
Use the same method as other providers to install the pulumi CLI. - Lock the version of the CLI and therefore codegen for consistent build results. - Ensure the local language plugins are using by disabling ambient plugins.
Does the PR have any schema changes?Looking good! No breaking changes found. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Continue to review full report in Codecov by Sentry.
|
| @@ -0,0 +1 @@ | |||
| 3.116.1 | |||
There was a problem hiding this comment.
@danielrbradley I don't think this is necessary if you bump the pu/pu version in go.mod. I'm using this provider as a bit of a testing ground to tighten up our dependency management, and getting rid of magic files like this is part of that goal.
There was a problem hiding this comment.
It was pulling the wrong dependency for me locally - was running a very old version of the language plugins. This is how we do it elsewhere, so standardisation seems like a good win to be able to understand different providers.
There was a problem hiding this comment.
If you're specifically wanting to pin codegen and pkg to the same version, you're probably better copying Ian's more complete approach which uses the proper installer:
$(PULUMI): HOME := $(WORKING_DIR)
$(PULUMI): provider/go.mod
@ PULUMI_VERSION="$$(cd provider && go list -m github.com/pulumi/pulumi/pkg/v3 | awk '{print $$2}')"; \
if [ -x $(PULUMI) ]; then \
CURRENT_VERSION="$$($(PULUMI) version)"; \
if [ "$${CURRENT_VERSION}" != "$${PULUMI_VERSION}" ]; then \
echo "Upgrading $(PULUMI) from $${CURRENT_VERSION} to $${PULUMI_VERSION}"; \
rm $(PULUMI); \
fi; \
fi; \
if ! [ -x $(PULUMI) ]; then \
curl -fsSL https://get.pulumi.com | sh -s -- --version "$${PULUMI_VERSION#v}"; \
fiThe downside of this is that it's a little harder to debug if it breaks compared to:
.pulumi/bin/pulumi: PULUMI_VERSION := $(shell cat .pulumi.version)
.pulumi/bin/pulumi: HOME := $(WORKING_DIR)
.pulumi/bin/pulumi: .pulumi.version
curl -fsSL https://get.pulumi.com | sh -s -- --version "$(PULUMI_VERSION)"Additionally, we've actually needed in the past to use different versions of codegen vs pkg reference .. which was one of the driving forces for introducing pulumi package gen-sdk. If we're unable to upgrade pkg for any reason, we might still need to take fixes to codegen.
There was a problem hiding this comment.
The downside of this is that it's a little harder to debug if it breaks compared to:
The downside I see with these solutions is that it's not straightforward to test against pre-release versions. Everything needs to already be published to get.pulumi.com, so working with local or remote branches means awkward environment variable overrides. I 100% agree that standardization should be the goal, but I also think in this case we've converged on some unnecessary complexity.
It was pulling the wrong dependency for me locally - was running a very old version of the language plugins. This is how we do it elsewhere, so standardisation seems like a good win to be able to understand different providers.
I remember now that when I was initially putting this together I ran into an issue with the python language plugin requiring an exec script. I punted on fixing that, hence why this was using your ambient plugins.
We can hack around that issue by vendoring the script for now. Here's what that looks like.
If we're unable to upgrade pkg for any reason, we might still need to take fixes to codegen.
I might not fully understand what you mean here, but pkg and sdk (as well as the language plugins) are still versioned separately.
There was a problem hiding this comment.
The downside I see with these solutions is that it's not straightforward to test against pre-release versions.
Working with testing local versions of codegen is a fairly unusual case on the providers team generally, though we should have this as part of the playbook. I'd suggest an alternative approach for locally testing specific codegen changes would be to run the dev build directly and not via make at all:
~/.pulumi-dev/bin/pulumi package gen-sdk bin/pulumi-resource-xyz --language python --version 2.0.0-dev
We can hack around that issue by vendoring the script for now.
From your link I see you're installing each plugin manually? e.g.
GOBIN=${WORKING_DIR}/bin go install github.com/pulumi/pulumi/sdk/nodejs/cmd/pulumi-language-nodejs/v3
This seems like it should work for the time being if you'd prefer that option, though I think it would be worth discussing deviating from using the official installer with the rest of the team as this setup looks quite unusual for any maintainers coming from other providers which we generally try to avoid.
There was a problem hiding this comment.
Working with testing local versions of codegen is a fairly unusual case on the providers team generally,
I must be unlucky then :)
though we should have this as part of the playbook. I'd suggest an alternative approach for locally testing specific codegen changes would be to run the dev build directly and not via make at all:
~/.pulumi-dev/bin/pulumi package gen-sdk bin/pulumi-resource-xyz --language python --version 2.0.0-devFrom your link I see you're installing each plugin manually? e.g.
GOBIN=${WORKING_DIR}/bin go install github.com/pulumi/pulumi/sdk/nodejs/cmd/pulumi-language-nodejs/v3This seems like it should work for the time being if you'd prefer that option, though I think it would be worth discussing deviating from using the official installer with the rest of the team as this setup looks quite unusual for any maintainers coming from other providers which we generally try to avoid.
I strongly agree with you re: deviation, but what's more unusual to me is that we're creating work for ourselves by inventing a new way to manage Go dependencies when the native toolchain should suffice.
- Need to use a different version locally? Use a
replacedirective. - Need to upgrade your local version? Use
go get. - Need to run a CLI pinned to a particular version? Use
go run. - Need to periodically bump a version? Use a tool like Dependabot which understands
go.mod(but not.pulumi.versionfiles).
A playbook would help but still has a discoverability problem. If I'm brand new to the team, why should I expect there to be two ways to manage dependencies?
There was a problem hiding this comment.
The purpose of downloading the CLI for codegen was to reduce our dependency on internal parts of the pulumi/pulumi codebase as these have caused issues in the past relating to breaking changes. Instead, the providers team consume the Pulumi CLI in the same way as any external users which makes compatibility easier to reason about.
Installing the Pulumi CLI & language plugins via the go toolchain is not a supported installation method and is likely to break. E.g. languages being moved to their own repos.
There's certainly nicities to treating it that way as you highlight, but it also requires the provider to be coupled to the internal implementation details of the CLI's build process rather than the public interface (the installer) which we advertise to our users.
Additionally, almost all providers don't have a root go.mod file - this would have to be integrated into the provider module.
There was a problem hiding this comment.
it sounds like there's a decision to be made across providers about the best way to manage the pulumi version, but let's not let that block us on getting the go version support rolled out.
IIUC, there's no strict dependency on avoiding ambient plugins, to start setting for RespectSchemaVersion? If so, I think we should just do that to move this forward.
I do agree with Daniel though that if possible, I'd rather have consistency in how we pin and download pulumi CLI across providers than an ideal approach applied to just 1 or 2 providers. That ultimately makes it easier to improve all providers later.
I think you two are on similar timezones this week, maybe you can get 30min to sync tomorrow and hash out a pragmatic approach?
There was a problem hiding this comment.
Yup, keen to get this in so have adopted the change from your branch @blampe if you're happy with that.
Ran a test locally and those changes fixed it for with with the extra change for make build which failed.
I also timed the pulumi CLI installation process:
- Using go install:
make bin/pulumi 25.44s user 13.49s system 88% cpu 44.224 total - Using curl:
make .pulumi/bin/pulumi 2.78s user 1.43s system 36% cpu 11.469 total
Let's revisit standardisation later.
There was a problem hiding this comment.
The purpose of downloading the CLI for codegen was to reduce our dependency on internal parts of the pulumi/pulumi codebase as these have caused issues in the past relating to breaking changes. Instead, the providers team consume the Pulumi CLI in the same way as any external users which makes compatibility easier to reason about.
Totally makes sense. Invoking the CLI this way doesn't make us any more dependent on code internals but does make us sensitive to knowing where the code lives, as you pointed out. The difference between this binary and the published one essentially boils down to the ldflag for Version, which can be somewhat alleviated with ReadBuildInfo.
golangci-lint is an example of a similar hermeticity problem. The linter and the code need to be updated together in cases when new breaking rules are added, but the linter's version is currently driven by ci-mgmt -- so workflow updates become blocked until someone takes the time to fix lint errors. It would be nice to instead let the repo decide the lint version it's compatible with, so its linter can be updated independently. One way to do that would be with a similar .golangci-lint.version file, but by leveraging go.mod instead we would have an approach that works for all tooling like this.
Additionally, almost all providers don't have a root go.mod file - this would have to be integrated into the provider module.
They should have a root go.mod, but that's a conversation for later :)
I also timed the pulumi CLI installation process:
- Using go install: make bin/pulumi 25.44s user 13.49s system 88% cpu 44.224 total
- Using curl: make .pulumi/bin/pulumi 2.78s user 1.43s system 36% cpu 11.469 total
Yeah, this is expected since it's compiled from source. The tools.go trick used here will be officially supported in go ~1.24 as go get -tool and should have nicer caching semantics.
Anyway thanks for indulging me again, as I mentioned I'd like to spend some more time flushing out a prototype to hopefully make the benefits more obvious.
| @@ -1,7 +1,7 @@ | |||
| { | |||
| "name": "docker-build", | |||
| "displayName": "docker-build", | |||
| "version": "0.0.2-alpha.1714063884+13fb5b61", | |||
| "version": "1.0.0-alpha.0+dev", | |||
There was a problem hiding this comment.
Shouldn't this be 0.0.2-alpha.x?
There was a problem hiding this comment.
This can be customised in the makefile by setting the default PROVIDER_VERSION. If you're currently working towards 1.0 then this would seem to make sense, but I can modify the makefile to be something like 0.1.0.1-alpha+dev if you think it's clearer.
- Fix depending on missing targets. - Make sdk/* phony beause they're folders - which can't be used for up-to-date targets. If any step after the folder is created fails, the folder already exists and won't be re-tried on the next run - leading to a bad state.
danielrbradley
added
the
impact/no-changelog-required
Part of pulumi/ci-mgmt#915
Install pulumi in standard way
Use the same method as other providers to install the pulumi CLI.
Enable respect schema version
Remove setting version at SDK build time