feat(api)!: sync generated SDK from staging (removes google_calendar + slack list endpoints)#7
feat(api)!: sync generated SDK from staging (removes google_calendar + slack list endpoints)#7aburkard wants to merge 1 commit into
Conversation
|
Firetiger has created a monitoring plan for this PR. |
aburkard
changed the title
![entelligence-ai-pr-reviews[bot]](https://avatars.githubusercontent.com/in/932812?s=60&v=4){kind=small}
| if echo "$UPLOAD_RESPONSE" | grep -q "HTTP/[0-9.]* 200"; then | ||
| echo -e "\033[32mUploaded build to Stainless storage.\033[0m" | ||
| echo -e "\033[32mInstallation: Download and unzip: 'https://pkg.stainless.com/s/hyperspell-cli/$SHA'. On macOS, run 'xattr -d com.apple.quarantine {executable name}'.\033[0m" | ||
| echo -e "\033[32mInstallation: Download and unzip: 'https://pkg.stainless.com/s/hyperspell-cli-staging/$SHA'. On macOS, run 'xattr -d com.apple.quarantine {executable name}'.\033[0m" |
There was a problem hiding this comment.
The script was synced from staging and now references hyperspell-cli-staging in the install URL. In the production repo (hyperspell/hyperspell-cli), users running this script receive installation instructions pointing to staging artifacts instead of production artifacts.
| echo -e "\033[32mInstallation: Download and unzip: 'https://pkg.stainless.com/s/hyperspell-cli-staging/$SHA'. On macOS, run 'xattr -d com.apple.quarantine {executable name}'.\033[0m" | |
| echo -e "\033[32mInstallation: Download and unzip: 'https://pkg.stainless.com/s/hyperspell-cli/$SHA'. On macOS, run 'xattr -d com.apple.quarantine {executable name}'.\033[0m" |
Prompt to fix with AI
Copy this prompt into your AI coding assistant to fix this issue.
In scripts/utils/upload-artifact.sh line 55, replace the hardcoded `hyperspell-cli-staging` with `hyperspell-cli` so the installation URL points to production artifacts. The staging path was incorrectly carried over during the sync from the staging buffer repository.
| permissions: | ||
| contents: read | ||
| id-token: write |
There was a problem hiding this comment.
The build job declares id-token: write but no step in the job requests an OIDC token — goreleaser only uses GITHUB_TOKEN. This grants unnecessary OIDC token minting capability, violating least-privilege.
| permissions: | |
| contents: read | |
| id-token: write | |
| permissions: | |
| contents: read |
Prompt to fix with AI
Copy this prompt into your AI coding assistant to fix this issue.
In .github/workflows/ci.yml, remove `id-token: write` from the build job's permissions block (lines 55-57). No step in the build job uses an OIDC token; only `contents: read` is required. This follows least-privilege security practices.
Confidence Score: 3/5 - Review RecommendedNot safe to merge without fixes — this PR syncs the generated SDK from staging and removes Google Calendar endpoints, which is valuable work, but a critical correctness issue was introduced: Key Findings:
Files requiring special attention
|
cb0d0bb to
75d412b
Compare
aburkard
changed the title
…1bfb8a9d0cdffb4 BREAKING CHANGE: removes the google_calendar integration endpoints, the slack integration list endpoint, and the box/google_calendar per-source options on memories search. Source: hyperspell/hyperspell-cli-staging@0ca6bc2 Promoted by: https://github.com/hyperspell/hyperspell/actions/runs/29068363046
1 participant
Promotes the generated SDK from the staging buffer to this production repo.
hyperspell/hyperspell-cli-staging@0ca6bc29f1dd5bbffa5195e0b1bfb8a9d0cdffb4(refmain)CHANGELOG.md, release-please manifest/config, the release-please/publish/release-doctor workflows, and version stamps (kept at0.2.0; release-please bumps them on release).Merging hands off to release-please: it will open a release PR computing the next version from this PR's conventional-commit message — that release PR is the human gate for the actual publish. Amend the commit type (
fix:/feat!:) before merging if the change warrants a different bump.A re-dispatch of the promote workflow force-pushes this branch, superseding this PR's content in place.