Conversation
|
I've successfully generated and reviewed the SDK changes locally using the devcontainer setup, but omitting those here for now so I can take a crack at testing the updated CI workflows. One particular concern I have with the updated CI is that it breaks (I think?) our previous release and versioning approach; depending on how opinionated pulumi/ci-mgmt is about this stuff, we may need to give up on some of our previous release workflow behavior. |
| on: | ||
| workflow_dispatch: | ||
| push: | ||
| tags: | ||
| - v*.*.* | ||
| - "!v*.*.*-**" |
There was a problem hiding this comment.
Our previous release workflow was a push-button workflow that determined the next release version by analyzing Conventional Commit tags in the git logs since the last release. Since this workflow file is autogenerated now, if we want to stick with push-button releases with version numbers determined by Conventional Commit tags, we can add a separate push-button workflow that determines the next release version and pushes that tag in order to trigger this workflow.
9d09826 to
2805323
Compare
2805323 to
2c876ce
Compare
The provider maintenance tools used in this repo have fallen far behind what is published by Pulumi. This brings us back in line with the latest pulumi/ci-mgmt tools so that we and our customers can benefit from the various improvements Pulumi has made over the past 18 months or more.
Unfortunately, because we let this get so outdated, this upgrade is guaranteed to lead to a lot of changes in SDK code. We will need to review those changes to confirm that new generated code is, as much as possible, functionally equivalent to previous generated code. That said, we may need to lean on our current
v0state to write off the changes so we can follow better provider maintenance practices going forward.