feat: Add /prerelease slash command for PyPI prereleases
#910
Conversation
Co-Authored-By: AJ Steers <[email protected]>
Original prompt from AJ Steers |
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. Testing This PyAirbyte VersionYou can test this version of PyAirbyte using the following: # Run PyAirbyte CLI from this branch:
uvx --from 'git+https://github.com/airbytehq/PyAirbyte.git@devin/1765592184-add-prerelease-command' pyairbyte --help
# Install PyAirbyte from this branch for development:
pip install 'git+https://github.com/airbytehq/PyAirbyte.git@devin/1765592184-add-prerelease-command'Helpful ResourcesPR Slash CommandsAirbyte Maintainers can execute the following slash commands on your PR:
Community SupportQuestions? Join the #pyairbyte channel in our Slack workspace. |
📝 WalkthroughWalkthroughAdds an on-demand "prerelease" slash command and supporting GitHub Actions workflow to build/publish prerelease Python packages; updates the slash command dispatcher and extends the reusable pypi_publish workflow to accept git_ref, version_override, and a publish flag. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant Dispatcher as Slash Command Dispatcher
participant GHWF as On-Demand Prerelease WF
participant Resolver as resolve-pr job
participant PypiWF as pypi_publish workflow
participant PyPI as PyPI/GitHub Release
participant Comments as PR Comments
User->>Dispatcher: Post "/prerelease" slash command
Dispatcher->>GHWF: Trigger workflow_dispatch (pr, comment-id)
GHWF->>Resolver: run resolve-pr (resolve meta, guard forks, compute version)
Resolver->>Comments: Post initial "building" comment
Resolver->>PypiWF: call pypi_publish with git_ref + version_override + publish=true
PypiWF->>PyPI: Build and upload package (or skip release upload if not a tag)
PypiWF-->>GHWF: return result (success/failure, outputs)
GHWF->>Comments: Post success comment with install instructions OR failure comment with logs and branch install fallback
Comments-->>User: Deliver post-result message
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
.github/workflows/prerelease-command.yml (3)
147-166: Consider clarifying fallback behavior on publish failure.This comment informs users they can "download the built wheel from the workflow artifacts" (line 166) when TestPyPI publish fails. However, there's no verification that artifacts are actually available or accessible. Since
continue-on-error: trueis intentional (per PR objectives), users should have a reliable way to access the prerelease artifacts.Wdyt about adding a check to confirm artifacts exist before pointing users to them? Or adding a direct link to the workflow run where they can download artifacts?
You could replace the vague "workflow artifacts" link with a more direct URL:
- > Or download the built wheel from the [workflow artifacts](${{ needs.start-workflow.outputs.job-run-url }}). + > Or download the built wheel from the [job artifacts](${{ needs.start-workflow.outputs.job-run-url }}#artifacts).This makes it more explicit where to find the artifacts.
101-103: Verify TestPyPi environment configuration.The workflow references environment "TestPyPi" (case-sensitive, line 102). Per the PR objectives, this environment must exist and be configured for OIDC trusted publishing. If the environment is misconfigured or doesn't exist, the workflow will fail with a cryptic GitHub error.
Consider adding a validation step or clearer documentation about the prerequisite environment setup. Should this be documented in the PR description or in a separate setup guide?
As a follow-up: Can you confirm the TestPyPi environment is already configured in the repository? If not, consider adding a setup guide or validation step.
168-183: Post-failure-comment job dependencies may miss some failures.The post-failure-comment job depends on
[start-workflow, build-prerelease](line 170) and usesif: failure(). However, if thestart-workflowjob itself fails, thepost-failure-commentjob won't run because it's listed as a dependency. Consider whether you want to catch failures even in the start-workflow step.If you want to ensure failure comments post even if start-workflow fails, you could add
always()to the condition:post-failure-comment: name: Post Failure Comment needs: [start-workflow, build-prerelease] - if: failure() + if: failure() && always() runs-on: ubuntu-latestBut note: this depends on whether you want to post comments for all types of failures. Wdyt?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/pr-welcome-community.md(1 hunks).github/pr-welcome-internal.md(1 hunks).github/workflows/prerelease-command.yml(1 hunks).github/workflows/slash_command_dispatch.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (6)
.github/pr-welcome-internal.md (1)
29-29: LGTM!Documentation is clear and consistently placed alongside other slash commands.
.github/workflows/slash_command_dispatch.yml (1)
37-37: LGTM!The command is correctly added to the allowlist in the expected format.
.github/pr-welcome-community.md (1)
30-30: LGTM!Consistent documentation across internal and community welcome messages.
.github/workflows/prerelease-command.yml (3)
105-108: Verify artifact handling and naming.The step downloads an artifact named "Packages" from the hynek build action. Please verify:
- Does
hynek/build-and-inspect-python-packageactually output an artifact named "Packages"?- Is the artifact path "dist" correct?
- If the artifact doesn't exist or has a different name, the TestPyPI publish step will silently fail to find packages.
Can you confirm the artifact name and path match what the hynek action produces? If they don't match, the workflow will fail silently at the download step.
125-146: Dependent on version extraction fix.The success comment references
needs.build-prerelease.outputs.version(line 135, 139), which will be incorrect until the version extraction logic is fixed (see earlier comment). Once that's addressed, this comment section should work correctly. The installation instructions look good otherwise — both TestPyPI and git-based installs are provided.Please fix the version extraction first, then verify the version shown here matches the actual dynamic version from the build.
1-22: Workflow structure and permissions look solid.The workflow dispatch inputs, permissions for OIDC trusted publishing, and job dependencies are well structured. The use of a custom resolve-ci-vars-action to extract PR metadata is a good pattern for slash-command workflows. The comments posted at each stage (start, success, failure) provide good visibility into the prerelease process.
Once the version extraction issue is addressed, this workflow should be in good shape. The graceful fallback on TestPyPI publish failures (via
continue-on-error: true) aligns well with the PR objectives.
…h workflow Co-Authored-By: AJ Steers <[email protected]>
…sion_override is provided Co-Authored-By: AJ Steers <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/prerelease-command.yml (1)
63-73: Harden the version compute script + fix ShellCheck quoting (SC2086)Could we add
set -euo pipefailand quote$GITHUB_OUTPUTto avoid word-splitting/globbing issues, wdyt? (Also aligns with the prior SC2086 finding.)- name: Compute prerelease version id: version run: | + set -euo pipefail # Get the latest tag version (strip 'v' prefix if present) LATEST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0") BASE_VERSION=${LATEST_TAG#v} @@ # Format: {base}.dev{pr_number}{run_id} (e.g., 0.34.0.dev825123456789) PRERELEASE_VERSION="${BASE_VERSION}.dev${{ github.event.inputs.pr }}${{ github.run_id }}" - echo "version=$PRERELEASE_VERSION" >> $GITHUB_OUTPUT + echo "version=$PRERELEASE_VERSION" >> "$GITHUB_OUTPUT" echo "Computed prerelease version: $PRERELEASE_VERSION"
🧹 Nitpick comments (1)
.github/workflows/prerelease-command.yml (1)
105-126: Failure path UX: consider also handling “publish failed but build succeeded”Right now, the failure comment only triggers on job failure, but a “publish failed, build succeeded” case could still want the git-install fallback instructions. Could we have the called workflow expose an output like
published: true|falseand branch the comment accordingly (or post both options on success), wdyt?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/pr-welcome-community.md(1 hunks).github/pr-welcome-internal.md(1 hunks).github/workflows/prerelease-command.yml(1 hunks).github/workflows/pypi_publish.yml(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/pr-welcome-internal.md
- .github/pr-welcome-community.md
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: yohannj
Repo: airbytehq/PyAirbyte PR: 716
File: airbyte/logs.py:384-402
Timestamp: 2025-07-11T19:53:44.427Z
Learning: In the PyAirbyte project, when reviewing PRs, maintain clear separation of concerns. Don't suggest changes that are outside the scope of the PR's main objective, even if they would improve consistency or fix other issues. This helps with reviewing changes and potential reverts.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (4)
.github/workflows/pypi_publish.yml (3)
48-51: Verify environment configuration supports both PyPI and TestPyPI publishing.The publish job uses a single
PyPienvironment for both tag-based releases and prerelease builds. However, PR objectives indicate a separateTestPyPienvironment should be used for prerelease versions.Currently, there's no conditional logic to select the environment based on trigger type. Should the code:
- Use different environments (e.g.,
PyPifor tags,TestPyPifor prerelease input)?- Dynamically set the environment name based on
inputs.publish?- Or is the assumption that the
PyPienvironment will be reconfigured per-deployment context?Wdyt on how to structure this to avoid accidentally publishing test versions to production PyPI?
35-37: Version override mechanism looks good.The
POETRY_DYNAMIC_VERSIONING_BYPASSenvironment variable is documented as the correct way to bypass the VCS mechanisms and use a static version, so this implementation should work as intended. The version computed in the prerelease workflow will be used directly during the build.
57-66: LGTM: Conditional upload logic.The release upload now correctly runs only for tag-based triggers, keeping GitHub release artifacts separate from prerelease builds.
.github/workflows/prerelease-command.yml (1)
84-104: Review comment is incorrect—package publishes to PyPI with correct namingThe workflow already publishes to production PyPI (not TestPyPI) with the correct package name
airbyte. The current install commandpip install airbyte==...is accurate. Additionally, the job dependency structure (wherepost-success-commentrequiresbuild-and-publishto succeed) and the separatepost-failure-commentjob (withif: failure()) already handle success/failure scenarios appropriately—there's no risk of posting a success message when publish fails.Likely an incorrect or invalid review comment.
…ITHUB_ENV Co-Authored-By: AJ Steers <[email protected]>
…th conditional steps Co-Authored-By: AJ Steers <[email protected]>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…e Status to PR Co-Authored-By: AJ Steers <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/prerelease-command.yml (2)
63-73: Version computation approach is solid and PEP 440 compliant.The prerelease version format (
0.34.0.dev{PR}{RUN_ID}) ensures uniqueness across multiple prerelease attempts and follows Python versioning standards. Sincegithub.run_idis globally unique, there's no collision risk.One minor suggestion: would it be worth adding a brief comment on line 70 documenting the version format for future maintainers, or is the current explanation sufficient?
106-122: Failure fallback and git install approach is solid.The fallback git install command (lines 119-122) provides good user experience when PyPI publish fails. The URL format is correct and will allow users to test the PR branch directly.
One note: This fallback assumes users can install from git. You may want to consider whether adding a note about installation requirements (e.g., "requires Git to be installed") would be helpful, but this is optional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/prerelease-command.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: yohannj
Repo: airbytehq/PyAirbyte PR: 716
File: airbyte/logs.py:384-402
Timestamp: 2025-07-11T19:53:44.427Z
Learning: In the PyAirbyte project, when reviewing PRs, maintain clear separation of concerns. Don't suggest changes that are outside the scope of the PR's main objective, even if they would improve consistency or fix other issues. This helps with reviewing changes and potential reverts.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (Fast)
- GitHub Check: Pytest (No Creds)
🔇 Additional comments (2)
.github/workflows/prerelease-command.yml (2)
75-82: Reusable workflow invocation looks properly structured, but needs verification of version override behavior.The job correctly passes
version_overrideandgit_refto the reusable workflow. However, I need to verify thatpypi_publish.ymlcorrectly uses theversion_overrideparameter to publish with the computed prerelease version (and doesn't fall back to poetry-dynamic-versioning).Can you confirm that the
pypi_publish.ymlworkflow:
- Respects the
version_overrideinput when set?- Publishes to the intended PyPI target (production PyPI, based on your earlier feedback)?
90-105: Success message lacks clarity on PyPI target, and PR objectives mention TestPyPI—need clarification.Your earlier feedback indicated you want "a real prerelease" on production PyPI (not TestPyPI), which makes sense. However, the PR objectives mention verifying a
TestPyPienvironment. The success message at line 98 currently says "Published to PyPI" without specifying which instance.Questions:
- Should the message explicitly state "Published to PyPI" (production) vs "Published to TestPyPI"?
- Are the TestPyPI environment checks in the objectives still relevant, or have you decided to publish directly to production PyPI?
This would help clarify the implementation intent.
…eeded Co-Authored-By: AJ Steers <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/prerelease-command.yml (2)
57-67: Consider version format to ensure chronological ordering across multiple prerelease builds.The current format
{base}.dev{pr}{run_id}works for uniqueness but can produce non-chronological version ordering. For instance, a later PR with a small run_id (e.g., PR#2 with run_id=1) would produce version0.34.0.dev21, while an earlier PR with a large run_id (e.g., PR#1 with run_id=99999999) produces0.34.0.dev199999999—and21 < 199999999, so the later version appears older in version comparisons.Would you consider using a separator like
{base}.dev{pr}.{run_id}(e.g.,0.34.0.dev2.1) to ensure proper sort ordering? This is still PEP 440 compliant and makes chronological relationships clearer.
91-99: Clarify prerelease context in success message.The success comment says "Published to PyPI" but doesn't indicate whether this is production PyPI or a test repository. Users reading this may try to install immediately and encounter issues if the version isn't available or if this is a TestPyPI-only release.
Would you consider adding a note about what this prerelease version is for (e.g., "This is a development prerelease for testing—ensure you understand version pinning before using in production")? This might also reference which PyPI repository the version was published to.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/prerelease-command.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (1)
.github/workflows/prerelease-command.yml (1)
36-67: Verify prerelease versioning integrates correctly with pypi_publish.yml.The custom versioning scheme here computes a dev version independently of poetry-dynamic-versioning. Ensure that pypi_publish.yml correctly applies the
version_overrideparameter to the build artifacts so the published package matches the version advertised in PR comments. Also verify this version format is accepted by your target PyPI repository (TestPyPI or production).Can you confirm:
- How does
pypi_publish.ymluse theversion_overrideparameter? (Does it override poetry-dynamic-versioning, or does it conflict?)- Which PyPI repository is the target? (The PR objectives mention TestPyPI, but want to confirm the actual behavior.)
- Does the TestPyPi environment exist in your repository settings with OIDC trusted publishing configured?
Co-Authored-By: AJ Steers <[email protected]>
Co-Authored-By: AJ Steers <[email protected]>
devin-ai-integration
bot
changed the title
aaronsteers
changed the title
/prerelease slash command for PyPI prereleases
Summary
Adds a new
/prereleaseslash command that allows maintainers to build and publish prerelease versions of PyAirbyte to PyPI directly from PRs. This enables testing PR changes viapip installwithout requiring a full release.Changes:
prerelease-command.ymlworkflow with 3 jobs: "Set up Workflow", "Call Publish Workflow", "Write Status to PR"pypi_publish.ymlto supportworkflow_callwithgit_ref,version_override, andpublishinputsslash_command_dispatch.ymlWorkflow behavior:
{base}.dev{pr_number}{run_id}(e.g.,0.34.0.dev825123456789)refs/pull/<PR>/headfor fork compatibilitypip install airbyte==<version>)Review & Testing Checklist for Human
PyPienvironment exists in GitHub repo settings with OIDC trusted publishing configured. The workflow will fail if this isn't set up correctly./prereleaseon a test PR after merging. This is the only way to verify the workflow actually works since it requires the slash command dispatch infrastructure.refs/pull/<PR>/headcheckout works correctly for fork contributions.Notes
PyPi(capital P) - ensure this matches the actual GitHub environment name exactly.pypi_publish.ymlviaworkflow_callto avoid duplicating build/publish logic.Link to Devin run: https://app.devin.ai/sessions/c86d36be59664129af00617d0e66bc4d
Requested by: AJ Steers (@aaronsteers)
Summary by CodeRabbit
/prereleasePR slash command to trigger on‑demand prerelease builds.✏️ Tip: You can customize this high-level summary in your review settings.