ci(pypi): add trusted publisher workflow for PyPI releases

[vitali87]

Summary

• Add GitHub Actions workflow that publishes to PyPI on release creation
• Uses OIDC trusted publishers (no API tokens needed)
• Requires the pypi GitHub environment (already created) and the pending publisher registered on PyPI (already configured)

Usage

1. Create a GitHub Release with a tag (e.g., v0.0.76)
2. The workflow builds with uv build and publishes via pypa/gh-action-pypi-publish

[gemini-code-assist]

Summary of Changes

Hello @vitali87, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new continuous integration workflow designed to automate the release process for PyPI. By integrating GitHub Actions with OIDC trusted publishers, it establishes a secure and efficient mechanism for deploying new versions of the package, thereby reducing manual overhead and enhancing security by removing the reliance on static API tokens.

Highlights

• PyPI Release Automation: Implemented a new GitHub Actions workflow to automatically publish releases to PyPI upon GitHub release creation.
• Secure Publishing: Utilized OIDC trusted publishers for authentication, eliminating the need for traditional API tokens.
• Workflow Requirements: The workflow depends on the 'pypi' GitHub environment and a pre-configured pending publisher on PyPI.
• Build and Publish Process: The workflow builds the package using 'uv build' and publishes it via 'pypa/gh-action-pypi-publish'.

Changelog

• uv.lock
  • Updated the 'code-graph-rag' package version from '0.0.75' to '0.0.76'.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/publish.yml

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the version of the code-graph-rag package in the uv.lock file to 0.0.76. This change aligns with the project's version bump and is a necessary step for the new PyPI publishing workflow. The update is correct and I see no issues.

[greptile-apps]

Greptile Summary

Adds a GitHub Actions workflow (.github/workflows/publish.yml) that publishes the package to PyPI when a GitHub Release is created, using OIDC trusted publishers via pypa/gh-action-pypi-publish. The uv.lock is updated to reflect the version bump to 0.0.76.

• The workflow follows existing repo conventions (uv for builds, actions/checkout@v4, astral-sh/setup-uv@v4)
• Issue: The job-level permissions block only specifies id-token: write, which overrides the top-level permissions: read-all — contents: read should be added for actions/checkout to work reliably
• The pypa/gh-action-pypi-publish action is referenced via a mutable branch (@release/v1) rather than a pinned SHA, which is inconsistent with the security posture in scorecard.yml

Confidence Score: 3/5

• The workflow is mostly correct but has a permissions gap that should be fixed before merging to ensure reliable builds.
• Score of 3 reflects that the core design is sound (OIDC trusted publishing, proper environment protection, reasonable triggers), but the missing contents: read permission is a real correctness issue that could cause the workflow to fail depending on GitHub's clone fallback behavior. The unpinned action reference is a secondary concern but relevant for a publish workflow touching the supply chain.
• publish.yml needs the contents: read permission added to the job-level permissions block.

Important Files Changed

Filename	Overview
.github/workflows/publish.yml	New GitHub Actions workflow for PyPI publishing via OIDC trusted publishers. Missing contents: read job-level permission (overrides top-level read-all), and action reference uses mutable branch instead of pinned SHA.
uv.lock	Lockfile version bump from 0.0.75 to 0.0.76, consistent with pyproject.toml. No other dependency changes.

Sequence Diagram

sequenceDiagram
    participant User as Developer
    participant GH as GitHub
    participant WF as publish.yml
    participant UV as uv build
    participant PyPI as PyPI (OIDC)

    User->>GH: Create Release (e.g. v0.0.76)
    GH->>WF: Trigger on release published
    WF->>GH: Checkout code (actions/checkout@v4)
    WF->>WF: Install uv (astral-sh/setup-uv@v4)
    WF->>WF: Set up Python 3.12
    WF->>UV: uv build
    UV-->>WF: dist/ artifacts (sdist + wheel)
    WF->>PyPI: Request OIDC token (id-token: write)
    PyPI-->>WF: Verify trusted publisher
    WF->>PyPI: Upload package (pypa/gh-action-pypi-publish)
    PyPI-->>GH: Published successfully

Loading

_{Last reviewed commit: 1a74fd1}

[greptile-apps]

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Missing contents: read permission

When permissions is set at the job level, it completely overrides the top-level permissions: read-all — unspecified permissions become none (except metadata). This means the actions/checkout step on line 20 has no contents: read permission.

For a public repository, actions/checkout may still succeed via an unauthenticated HTTPS clone fallback, but this is fragile and not the intended behavior. If the repo ever becomes private, or if GitHub changes fallback behavior, the workflow will break. The build-binaries.yml workflow in this repo correctly sets contents: write at the job level for the same reason.

Suggested change

	permissions:
	id-token: write
	permissions:
	id-token: write
	contents: read

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/publish.yml
Line: 15-16

Comment:
**Missing `contents: read` permission**

When `permissions` is set at the job level, it **completely overrides** the top-level `permissions: read-all` — unspecified permissions become `none` (except `metadata`). This means the `actions/checkout` step on line 20 has no `contents: read` permission.

For a public repository, `actions/checkout` may still succeed via an unauthenticated HTTPS clone fallback, but this is fragile and not the intended behavior. If the repo ever becomes private, or if GitHub changes fallback behavior, the workflow will break. The `build-binaries.yml` workflow in this repo correctly sets `contents: write` at the job level for the same reason.

```suggestion
    permissions:
      id-token: write
      contents: read
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Action pinned to branch, not SHA

The pypa/gh-action-pypi-publish action is referenced via @release/v1, which is a mutable branch ref. This repo's scorecard.yml pins actions to commit SHAs for supply-chain security (e.g., actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683). While @release/v1 is the pattern recommended by PyPA's own documentation, pinning to a specific SHA would be more consistent with the security posture demonstrated by the Scorecard workflow and would prevent a compromised upstream from injecting malicious code into the publish step — which is particularly sensitive since it pushes packages to PyPI.

Consider pinning to a specific commit SHA:

Suggested change

	uses: pypa/gh-action-pypi-publish@release/v1
	uses: pypa/gh-action-pypi-publish@76f52bc884231f62b54571ab1b17f0ab24dba305 # release/v1

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/publish.yml
Line: 37

Comment:
**Action pinned to branch, not SHA**

The `pypa/gh-action-pypi-publish` action is referenced via `@release/v1`, which is a mutable branch ref. This repo's `scorecard.yml` pins actions to commit SHAs for supply-chain security (e.g., `actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683`). While `@release/v1` is the pattern recommended by PyPA's own documentation, pinning to a specific SHA would be more consistent with the security posture demonstrated by the Scorecard workflow and would prevent a compromised upstream from injecting malicious code into the publish step — which is particularly sensitive since it pushes packages to PyPI.

Consider pinning to a specific commit SHA:
```suggestion
        uses: pypa/gh-action-pypi-publish@76f52bc884231f62b54571ab1b17f0ab24dba305 # release/v1
```

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.