Hello everybody, this is Francisco. We are in the process of publishing our upcloud pulumi bridge provider, we already created the PR for it. We would like to automate the upgrade of the provider and sdks as much as we can. We would like to trigger the update process once we create a new version of our terraform provider. We are generating the workflows in our pulumi-upcloud using the

xternal-bridged-provider

template and then calling make ci-mgmt. Below I am detailing the process we think we need to implement to upgrade the provider and sdks. Can somebody take a look at it andlet us know if this is ok? I appreciate it! 1. Make Changes to the Terraform Provider Modify the Terraform provider source code to add/update resources, data sources, or functionality. Commit and push the changes to the repository. 2. Upgrade the Pulumi Provider Using the Terraform Bridge The Pulumi provider is generated from Terraform using the Pulumi Terraform Bridge. To sync the changes, you need to run the bridge upgrade process. How to trigger the upgrade process: Manually trigger it via GitHub Actions: Go to GitHub → Actions → "Upgrade Provider" workflow (upgrade-provider.yml). Click "Run workflow" and provide the necessary version input. Automatically trigger it (scheduled upgrade): The upgrade-provider.yml workflow runs every day at 3 AM UTC to check for updates. Relevant Workflow: ✅ upgrade-provider.yml (Triggered manually or scheduled) This workflow: Upgrades the Pulumi provider to use the latest Terraform provider. Uses upgrade-provider to regenerate the provider code. Commits and pushes the updates to a new branch. Creates a pull request to merge the changes. 3. Review and Merge the Upgrade PR After the upgrade, a pull request is created automatically with the updated provider code. A developer needs to review and merge the PR to integrate the changes into main. Relevant Workflow: ✅ pull-request.yml (Runs on PR creation) This workflow: Adds a comment to the PR. Notifies maintainers that they can run acceptance tests. 4. Run Acceptance Tests to Validate the Upgrade Once the upgrade PR is ready, acceptance tests must be run to ensure that the Pulumi provider still functions correctly. How to trigger the tests: Comment /run-acceptance-tests on the pull request. This triggers the run-acceptance-tests.yml workflow. Relevant Workflows: ✅ run-acceptance-tests.yml (Triggered via PR comment or automatically) This workflow: Builds the provider. Runs acceptance tests. If the tests fail, the PR needs further changes before merging. 5. Merge the Upgrade PR If all tests pass, merge the PR into the main branch. Relevant Workflow: ✅ main.yml (Triggered on push to main) This workflow: Builds the provider. Runs tests. Publishes an internal pre-release version. Checks if a full release is needed. 6. Tag a New Release Once the upgrade is complete, a new version must be released. A maintainer tags a new release using a semantic version (vX.Y.Z). Relevant Workflows: ✅ release.yml (Triggered when a release tag is pushed (vX.Y.Z)) This workflow: Builds the final provider. Runs final tests. Publishes the provider to Pulumi. ✅ verify-release.yml (Runs after publishing) This workflow: Verifies that the published provider works correctly.

Hey @hundreds-truck-17153, that looks about right. Let us know if you hit any trouble along the way!