Repository navigation
Tags
Tags
feat: Upgrade pulumi-terraform-bridge to v3.141.0 (#364) This PR was generated via `$ upgrade-provider equinix/pulumi-equinix --kind=bridge --target-bridge-version=v3.141.0 --pr-title-prefix=feat: --allow-missing-docs=false`. --- - Upgrading pulumi-terraform-bridge from v3.139.0 to v3.141.0. --------- Co-authored-by: pulumi-bot <bot@pulumi.com>
feat: Upgrade terraform-provider-equinix to v5.3.0 (#362) This PR was gen 8000 erated via `$ upgrade-provider equinix/pulumi-equinix --kind=provider --target-bridge-version=latest --target-version=5.3.0 --allow-missing-docs=true`. --- - Upgrading terraform-provider-equinix from 5.2.0 to 5.3.0. Fixes #361 --------- Co-authored-by: pulumi-bot <bot@pulumi.com>
fix: generate SDKs with the release version (#358) ## Summary The v0.33.0 release failed in `publish_sdk`: ``` Found version v${VERSION} does not match expected version v0.33.0 ``` The Node.js SDK's `package.json` still had the codegen placeholder `"${VERSION}"`. Pulumi's codegen only writes the provider version into the SDK packages when the language info sets `RespectSchemaVersion`; the old Makefile filled the version in with `sed` after generation, and the ci-mgmt Makefile doesn't. Python would also have been built as `0.0.0`, and the .NET `.csproj` had no `<Version>`. This change: - Enables `RespectSchemaVersion` for Node.js, Python, Go and .NET in `provider/resources.go`, as other ci-mgmt bridged providers (e.g. pulumi-gcp) do. CI's `build_sdk` generates the SDKs with `PROVIDER_VERSION`, so the published packages get the release version. The committed SDKs carry the `0.0.0-alpha.0+dev` placeholder. - Generates `pyproject.toml` instead of `setup.py` for Python (`PyProject.Enabled`). The version is written into the packaging file, and the `build_sdk` "Check worktree clean" step allows `pyproject.toml` to change but not `setup.py`. `pyproject.toml` declares the same name, dependencies, `requires-python`, metadata and package data as the old `setup.py`. - Regenerates the schema and SDKs. The only SDK changes are the version fields in `package.json`, `pyproject.toml`, the `.csproj`, the `pulumi-plugin.json` files and the Go `pulumiUtilities.go`. The Go SDK now pins the provider plugin version it requests to the SDK version, like the other SDKs; previously it requested no specific version. ## Release follow-up Re-running the failed v0.33.0 release won't pick this up, since it builds from the tagged commit. After merging, either run `equinix-tag-release` to release v0.33.1, or delete the v0.33.0 GitHub release and tag and run it again. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
ci: push release tags with the automation token (#357) ## Summary The `equinix-tag-release` workflow created the `v0.33.0` tag, but the tag push didn't trigger `release.yml`. `actions/checkout` persists `GITHUB_TOKEN` (default `persist-credentials: true`) as an `http.https://github.com/.extraheader` `AUTHORIZATION` header, and git sends that header instead of the credentials in the push URL. So the tag was pushed with `GITHUB_TOKEN` rather than `PULUMI_PROVIDER_AUTOMATION_TOKEN`, and [events triggered by `GITHUB_TOKEN` don't start other workflows](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow). This sets `persist-credentials: false` on the checkout, so the push authenticates with the automation token from the push URL. semantic-release's dry run is unaffected: it builds its own authenticated URL from the `GITHUB_TOKEN` in its environment. It also keeps the automation token out of the git config, so the semantic-release step (which installs packages from npm at runtime) can't read it. ## After merging `release.yml` only runs on tag pushes, so `v0.33.0` needs to be pushed again to trigger it: either delete the remote tag and push it from a user account, or delete it and re-run `equinix-tag-release`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
PreviousNext