Rebuild on ci-mgmt #135
Rebuild on ci-mgmt #135
Conversation
Does the PR have any schema changes?Found 1 breaking change: Functions
New functions:
Maintainer note: consult the runbook for dealing with any breaking changes. |
There was a problem hiding this comment.
I think this is a step in the right direction, but bringing the whole bridged provider boilerplate over is quite a lot. I'm concerned that we leave users enough information to operate all the workflows and I think we need a clear message on whether they should try to keep up to date with out ci-mgmt. I'm worried that if users try to stay up on latest ci-mgmt, we'll end up breaking them regularly. But of course all these workflows tell you not to edit them since they are managed by ci-mgmt.
Also had the idea that maybe we can have a test initialization in pulumiverse as well as testing that we can recreate pulumi-xyz. That would help us validate that we don't break things for non-pulumi orgs.
|
I've made significant progress on finishing up refining the documentation. This achieves the aim of leveraging ci-mgmt for the boilerplate which means we can focus on making improvements in ci-mgmt and they'll naturally flow into the repo too. Once this is merged, we'll onboard this repo into the ci-mgmt nightly push process to keep it up to date. I'd recommend also previewing how the instructions flow from this starting point: https://github.com/pulumi/pulumi-tf-provider-boilerplate/tree/rebuild-on-ci-mgmt?tab=readme-ov-file#terraform-bridge-provider-boilerplate |
As suggested during work on the TF boilerplate: pulumi/pulumi-tf-provider-boilerplate#135 (comment)
danielrbradley
requested review from
guineveresaenger
and removed request for
ringods
There was a problem hiding this comment.
I love this!
To reduce noise and delineate these changes, is it possible to break this up into 3-4 separate PRs, or at least three commits that will not be squashed?
- Workflow generation
- New and improved examples
- New setup tooling + schemagen
- SDK generation (can be separate commit on xyz setup)
Yup, can do a final rebase once the overall change looks good enough for an initial changeover. Will have a play with exactly how it can divide up. |
These will be replaced with workflows provided by ci-mgmt in a later commit.
- Copy from the pulumi/pulumi-xyz provider repo. - Respect schema version. This enables SDKs using the correct version of the provider plugin. - Use pyproject. - Add real configuration and types. - Remove SDK dependencies where possible to let codegen pick its own dependencies. - Update go module dependencies.
- Use defaults most appropriate for third parties which will still work for internal use too. - Document the purpose of each option. - Link to where to find all other options within the ci-mgmt defaults file.
Include usable SDKs in the repo for people exploring the expected structure.
- Add basic TS and Python example programs. - Include useful default test setups which match our standard provider conventions (using tags etc). - Add base options for all languages. - Set `binPath` to avoid the user having to modify their global PATH. - Skip all tests initially as the upstream provider doesn't have read, update or delete implemented so will fail the test.
Put the main documentation into SETUP.md so the README.md looks more like a normal provider, with just an additional lead paragraph explaining the project's purpose and linking to the SETUP.md Use a standalone `setup.sh` script instead of a custom makefile target so it doesn't get overwritten by ci-mgmt updates. - Make the script interactive by default to be more user-friendly. - Allow the script to be run non-interactively (such as in CI for our own testing) via flags for inputs. - `-v` enables verbose mode which prints all commands and evaluated conditions. - On any error, print out a clear notification of failure including the originating line number.
danielrbradley
force-pushed
the
rebuild-on-ci-mgmt
branch
from
2e0e0d5
to
2d6d014
Compare
|
This is now rebased into 7 meaningful chunks which we will preserve in the git history. |
Related to: https://github.com/pulumi/home/issues/3644
Leverage pulumi/ci-mgmt/provider-ci for generating the makefile and GitHub workflows so we don't have to maintain a separate set in the boilerplate. We will onboard this repo to the automated ci-mgmt nightly push process to keep this repo up-to-date with changes. This also makes it easier for consumers of the boilerplate to stay up-to-date with CI and build changes we're making internally by running
make ci-mgmtrather than having to mainting all parts of the build after forking the repo.Use our internal "xyz provider" in the boilerplate as a more real test which is a working provider which can be used for testing. The plan is to test the initialization script by regularly re-initializing our internal pulumi-xyz repo from this boilerplace to ensure it still produces a functional provider.
Improve the automated replacement of the provider name by splitting out a new
setup.shscript (instead of being a custommake preparetarget) which provides inline documentation, interactive prompting, verbose logging and error line numbers for debugging issues. This can also be more easily extended to handle additional aspects such as the location of the provider module and any required internal module shimming.