Typed provider configuration #1126
Conversation
| @@ -5,7 +5,6 @@ major-version: 0 | |||
| providerDefaultBranch: main | |||
| upstreamProviderOrg: vancluever | |||
| publishRegistry: false | |||
| enableAutoRelease: false | |||
There was a problem hiding this comment.
Only used by acme and not referenced in templates -- safe to remove.
There was a problem hiding this comment.
Yup, this was added but then refactored away in the same PR it appears with just this left-over.
provider-ci/internal/pkg/templates/bridged-provider/.github/workflows/upgrade-provider.yml
Show resolved
Hide resolved
provider-ci/internal/pkg/templates/bridged-provider/.github/workflows/upgrade-provider.yml
Outdated
Show resolved
Hide resolved
provider-ci/internal/pkg/templates/bridged-provider/.github/workflows/upgrade-provider.yml
Outdated
Show resolved
Hide resolved
|
Is there any option to conbine the defaults into the parser too so we don't have to maintain the defaults file separately? |
Sure! I kept it around since this is already a pretty big change but that's very doable. |
| makeTemplate: bridged | ||
| template: bridged-provider |
There was a problem hiding this comment.
Does this mean we need to roll out a change to every provider to update this field?
There was a problem hiding this comment.
Or is this a mis-typed field in the config that had no effect?
There was a problem hiding this comment.
Looks like it's set in 74 providers https://github.com/search?q=org%3Apulumi+makeTemplate+path%3A.ci-mgmt.yaml&type=code
There was a problem hiding this comment.
Or is this a mis-typed field in the config that had no effect?
Yep! makeTemplate has no effect, so these all default to using the bridge template anyway. We'll continue to allow them to specify makeTemplate, and it'll continue to be a no-op.
There was a problem hiding this comment.
Overall looks good. Nice to have some real types involved which should make it easier to keep track of valid fields.
Would be nice to not have the documentation duplicated between the types and the defaults at some point, but that could be a follow-up task.
We'll also need a roll-out plan for fixing any bad fields in config files.
Agree and created #1146
We should get build failure issues for any providers specifying some bad fields not allow-listed here, and I can fix those as needed. Otherwise cleaning these up isn't urgent (arguably not worth doing). IMO it's more important that the boilerplate repos reflect the correct usage and I think you already took care of that. |
This adds strong typing around our CI configuration options.
Currently our config is just a bag of values, which has led to repos specifying options which have no effect on CI (e.g.
parallel:,makeTemplate:etc.).This adds types for all of our available options and will fail if
ci-mgmt.ymlspecifies an unrecognized option. For backwards compatibility we continue to allow existing no-op params in order to not break existing providers.