Consolidate go modules for bridged providers #1238
Conversation
blampe
force-pushed
the
blampe/modules
branch
from
2536917 to
e449d4e
Compare
|
@ringods wanted to put this on your radar. This would move us towards a more idiomatic layout for these projects but I don't want it to be a surprise for pulumiverse. |
blampe
force-pushed
the
blampe/modules
branch
from
e449d4e to
8d8e12d
Compare
blampe
force-pushed
the
blampe/modules
branch
from
8d8e12d to
b9e1a2c
Compare
There was a problem hiding this comment.
@blampe may I ask for one addition to this PR?
Users working with VSCode to manage a provider (me included), add a go.work and go.work.sum file at the root of the repo currently. This is required for VSCode to have proper code completion in the different folders which currently have a go.mod file.
In this PR, you consolidate these go.mod files into a single one at the root. Can you either add go.work and go.work.sum to getDeletedFiles or make it part of your migration?
@ringods done! If there is a |
blampe
force-pushed
the
blampe/modules
branch
from
b1bc34c to
b55398b
Compare
The `./tests` modules currently depends on the `./provider` module for some OpenAPI helpers, but `./provider` also depends on `./tests` for Gomega matchers. Since `./tests` isn't versioned like a proper module this puts us in a situation where Renovate will continuously try to update it #3384 We can teach Renovate to ignore this bump, or we can break the dependency by moving some code around. I've opted for the latter, moving `tests/gomega` to `provider/pkg/gomega`. (This makes it easier to consume from other projects if we want to.) Of course it's worth mentioning this is a self-inflicted problem due to our module structure. Related pulumi/ci-mgmt#1238.
This introduces a migration to automatically consolidate
./{provider,examples,tests}/go.modunder a single./go.mod. The SDK module isn't modified so users are NOT impacted.Examples:
(Try it yourself by running
go run github.com/pulumi/ci-mgmt/provider-ci@8953abeef73baacb2c592e96158afe9c29e94255 generatein a bridged provider.)This gives us significantly more flexibility with regard to how we choose to organize our unit and integration tests. In particular it becomes straightforward to run integration tests under
./examplesand./providerssimultaneously because they now belong to the same module. (We currently run one and then wait for it to complete before starting the other, but this sacrifices parallelism while waiting for long polls to complete.)This is essentially an alternative to the
integrationTestProvideroption with a number of add benefits, including better performance and an improved overall developer experience.#1039 (removing arbitrary injection hooks) will be further unblocked after this:
go test -tags=${{ matrix.language }} ...from the repository root will now capture integration tests under./examplesas well as./provider.This only benefits bridged providers, but we are very close to being able to put native providers on the same (or very similar) workflows as bridged providers -- at which point the same migration can be applied.
Related: