Skip to content

Conversation

@ctreatma
Copy link
Contributor

This PR aims to fix our broken CI workflows and make it easier to catch up with future changes to how bridged Pulumi providers are developed.

I added an initial .ci-mgmt.yaml file and then ran the provider-ci tool as described in the pulumi/ci-mgmt docs to generate the standard Pulumi workflows.

@@ -1,42 +0,0 @@
# WARNING: This file was build based on https://github.com/pulumi/ci-mgmt
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the upgrade-provider workflow has been updated to run on a schedule instead of running when an issue is opened, so there's no longer a need for a separate check workflow that discovers new provider versions and creates an issue.

id-token: write # For ESC secrets.

env:
GH_TOKEN: ${{ secrets.EQUINIX_BOT_TOKEN }}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the updated workflows look for PULUMI_PROVIDER_AUTOMATION_TOKEN, so we can put our token there instead. That's likely more straightforward than modifying the generated workflows to keep our old bot token secret name.

Comment on lines -29 to -30
PULUMI_SKIP_MISSING_MAPPING_ERROR: true
PULUMI_SKIP_EXTRA_MAPPING_ERROR: true
Copy link
Contributor Author

@ctreatma ctreatma Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We manually added these PULUMI_SKIP_ environment variables to a couple of workflows to smooth out the upgrade process. Having these in all workflows would be bad--we don't want to release broken providers--but it doesn't look like pulumi/ci-mgmt gives the kind of granular control we would need to only have these environment variables in some workflows but not in others. It's probably better to lose these if it means we can follow a standard development process.

name: publish
runs-on: ubuntu-latest
outputs:
new_release_version: ${{ steps.semantic_release.outputs.new_release_version }}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to move this semantic release logic to a separate workflow file so that it is not overwritten by ci-mgmt. If it isn't already, the semantic release workflow will need to be created with our own bot token so that the tag it creates will trigger this ci-mgmt-managed release workflow.

@equinix equinix deleted a comment from apiiro bot Oct 29, 2025
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

Maintainer note: consult the runbook for dealing with any breaking changes.

@@ -1,24 +1,37 @@
# WARNING: This file is autogenerated - changes will be overwritten when regenerated by https://github.com/pulumi/ci-mgmt

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The updated linter is failing, so we should revert to the old files for now. We can regenerate the new linter stuff later.

Makefile Outdated
$(WORKING_DIR)/bin/${TFGEN} schema --out provider/cmd/${PROVIDER}
(cd provider && VERSION=$(VERSION) go generate cmd/${PROVIDER}/main.go)

bin/pulumi-java-gen: .pulumi-java-gen.version $(PULUMICTL_BIN)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should bring back the old java gen logic for now and then upgrade to the bridge-native java generator in a follow-up PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we need to manually navigate the transition from pulumi-java-gen to pulumi-language-java regardless of what CI is in place, we might as well get #311 figured out first and then revisit this one after we've dropped pulumi-java-gen.

@ctreatma ctreatma force-pushed the set-up-ci-mgmt branch 2 times, most recently from f329d57 to 6bd72bb Compare November 6, 2025 15:36
@apiiro
Copy link

apiiro bot commented Nov 6, 2025

⚠️ Apiiro found 4 new risks - 4 high ⚠️

🔴 High: Exposed Secrets with Unknown Validity in Public, Applicative Code - High in secret of type User password
  • Secret type: User password
  • Validity: No validator
  • Exposure: Exposed
  • File type: Source Code
  • Appearances: Appears 1 time in the file
  • Preview: * .password("•••••") line 45
  • Insights: Public repository
🔴 High: Exposed Secrets with Unknown Validity in Public, Applicative Code - High in secret of type User password
  • Secret type: User password
  • Validity: No validator
  • Exposure: Exposed
  • File type: Source Code
  • Appearances: Appears 1 time in the file
  • Preview: * final var bgpPassword = "•••••"; line 54
  • Insights: Public repository

Repository: pulumi-equinix
Applications: ORG - EQUINIX

View in Apiiro

@ctreatma ctreatma changed the base branch from main to fix-upgrade-provider-action November 6, 2025 15:51
@ctreatma ctreatma changed the base branch from fix-upgrade-provider-action to drop-pf-shim November 6, 2025 16:34
- Checked out github.com/pulumi/ci-mgmt
- Built the `provider-ci` tool
- Ran `./bin/provider-ci generate --name equinix/pulumi-equinix --config ~/Documents/code/pulumi-equinix/.ci-mgmt.yaml --out ~/Documents/code/pulumi-equinix/`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants