Skip to content

ci: migrate pypi_publish workflow from PAT to octavia-bot GitHub App #607

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

ci: migrate pypi_publish workflow from PAT to octavia-bot GitHub App #607

wants to merge 3 commits into from
+10 −2

Conversation

devin-ai-integration[bot]
Copy link
Contributor

@devin-ai-integration devin-ai-integration bot commented Jun 23, 2025 •
edited by aaronsteers
Loading

More info:

Migrate pypi_publish workflow from PAT to octavia-bot GitHub App

This PR migrates the pypi_publish.yml workflow from using the "Octavia Maintenance" PAT (GH_PAT_MAINTENANCE_OCTAVIA) to the octavia-bot GitHub App authentication. This resolves PAT rate limit failures by using GitHub App tokens which have higher rate limits and are more secure.

Changes Made

  • Added two GitHub App token generation steps using actions/create-github-app-token@v2
  • Updated checkout step to use the first generated GitHub App token instead of PAT
  • Updated create-pull-request step to use the second generated GitHub App token instead of PAT
  • Implemented dual token generation to handle the 1-hour GitHub App token lifetime - tokens are generated immediately before each usage

Technical Details

Token Lifetime Management

Following feedback about GitHub App token limitations, this implementation generates tokens twice:

  1. Before checkout step - get-checkout-token for accessing airbyte-platform-internal repository
  2. Before PR creation - get-pr-token for creating pull requests

This ensures we never hit the 1-hour expiration limit even if the workflow takes a long time between these steps.

Implementation Pattern

  • Uses actions/create-github-app-token@v2 (following PyAirbyte pattern)
  • Scoped specifically to the airbyte-platform-internal repository
  • Requires OCTAVIA_BOT_APP_ID and OCTAVIA_BOT_PRIVATE_KEY secrets

Benefits

  • Higher rate limits - GitHub App tokens have higher rate limits than PATs
  • Better security - Tokens are scoped to specific repositories and have shorter lifespans
  • Resolves rate limit failures - Addresses the original issue with PAT rate limiting

Comprehensive List of Workflows Using "Octavia Maintenance" PAT

Based on my analysis across all three repositories, here are all workflows currently using GH_PAT_MAINTENANCE_OCTAVIA:

airbytehq/airbyte

  • .github/workflows/poe-command.yml (line 50)
  • .github/workflows/slash-commands.yml (line 21)
  • .github/workflows/bump-version-command.yml (line 97)
  • .github/workflows/label-prs-by-context.yml (lines 16, 19)
  • .github/workflows/label-github-issues-by-context.yml (lines 14, 17)
  • .github/workflows/stale-community-issues.yaml (line 27)
  • .github/workflows/stale-routed-issues.yaml (line 25)

airbytehq/airbyte-python-cdk

  • .github/workflows/pypi_publish.yml (lines 282, 305) - ✅ MIGRATED IN THIS PR
  • .github/workflows/poe-command.yml (line 28)
  • .github/workflows/slash_command_dispatch.yml (line 18)

airbytehq/PyAirbyte

  • .github/workflows/slash_command_dispatch.yml (line 22)

Testing

The workflow changes have been validated for:

  • ✅ YAML syntax correctness
  • ✅ No remaining PAT references in target file
  • ✅ Proper GitHub App token generation and usage
  • ✅ Correct secret references

Link to Devin run

https://app.devin.ai/sessions/dab84139d9d74eafa65ab285f12ccd39

Requested by: AJ Steers (aj@airbyte.io)

@devin-ai-integration @aaronsteers
ci: migrate pypi_publish workflow from PAT to octavia-bot GitHub App
be90253 
- Replace GH_PAT_MAINTENANCE_OCTAVIA with octavia-bot GitHub App authentication
- Add two GitHub App token generation steps using actions/create-github-app-token@v2
- Generate tokens immediately before each usage to avoid 1-hour expiration
- Update checkout and create-pull-request steps to use generated tokens
- Resolves PAT rate limit issues by using GitHub App tokens

Co-Authored-By: AJ Steers <aj@airbyte.io>
@devin-ai-integration Devin.ai Integration
Copy link
Contributor Author

Original prompt from AJ Steers:

Received message in Slack channel #ask-devin-ai:

@Devin - Make a list of workflows that use the "Octavia Maintenance" PAT in github CI workflows within `airbytehq/airbyte`, and `airbyte-python-cdk` , and PyAirbyte. Then, specifically create a PR for this one (<https://github.com/airbytehq/airbyte-python-cdk/blob/577f9a77c217fa966afbe5a9d835738f81e55fe0/.github/workflows/pypi_publish.yml|.github/workflows/pypi_publish.yml>), moving it over to the `octavia-bot` GitHub App. This is to resolve failures related to the PAT rate limit. You should find examples of this in the airbyte repo or in the PyAirbyte repo. Use the same re-usable actions approach to keep it DRY and easy to maintain.

@devin-ai-integration Devin.ai Integration
Copy link
Contributor Author

devin-ai-integration bot commented Jun 23, 2025 •
edited by aaronsteers
Loading

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment and CI monitoring

@github-actions github-actions bot added the ci label Jun 23, 2025
aaronsteers
aaronsteers reviewed Jun 23, 2025
View reviewed changes
@aaronsteers aaronsteers requested a review from dbgold17 June 23, 2025 18:45
@devin-ai-integration @aaronsteers
fix: update create-pull-request to use correct token reference
c4ab2ca 
- Fix reference from removed get-pr-token step to existing get-checkout-token step
- Ensures workflow doesn't fail when trying to create PR with non-existent token

Co-Authored-By: AJ Steers <aj@airbyte.io>
@github-actions GitHub Actions
Copy link

PyTest Results (Fast)

3 667 tests  ±0   3 656 ✅ ±0   6m 5s ⏱️ +3s
    1 suites ±0      11 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit c4ab2ca. ± Comparison against base commit 577f9a7.

aaronsteers
aaronsteers approved these changes Jun 23, 2025
View reviewed changes
Copy link
Contributor

@aaronsteers aaronsteers left a comment

Choose a reason for hiding this comment

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

✅ Approved. This matches the existing proven patterns of using GitHub App token instead of a PAT, and should permanently resolve the rate limit issue that we've seen on this workflow.

@dbgold17
Copy link
Contributor

@aaronsteers catching up here and this makes sense to me. What is the history behind having a GH app for some jobs and this maintenance PAT for other jobs?

I saw your concern about expiring GH tokens for long-running jobs. It seems like the GH action we use to get the token from the GH app doesn't handle refreshing automatically but we shouldn't care about that here since the steps of this job should be fast. Is that right?

@aaronsteers
Copy link
Contributor

@aaronsteers catching up here and this makes sense to me. What is the history behind having a GH app for some jobs and this maintenance PAT for other jobs?

@dbgold17 - The PAT method is a bit older and simpler than the GitHub App auth approach, but GitHub App is recommended as the best practice for most use cases, and GitHub advises using a GitHub App instead of a PAT for all automation use cases.

Also, GitHub Apps have 3x of the hourly rate limit (15K instead of 5K requests). When I submitted the help ticket to GitHub Support requesting a rate limit, they advised about this difference and suggested migrating to GitHub App. There's a few other advantages as well, but long story short: we can and probably should just eventually migrate everything from PAT to GitHub App.

Caveats:

  1. The token retrieved by a GitHub App login is only valid for one hour. That doesn't affect this workload, but any workflows that need to use the token for a workload running longer than an hour should re-login for a new token before performing tasks at the end of the pipeline.
  2. Even with 3x the limit, very spammy workloads like the up-to-date pipeline, and maybe the auto-labeler, should still probably use their own GitHub App. Better to have those spammy operations overload their own limit than to affect other core operations globally across the GitHub infrastructure. (For instance, slash commands not running or PyPi publish not working, as is the case on this PR.)

I saw your concern about expiring GH tokens for long-running jobs. It seems like the GH action we use to get the token from the GH app doesn't handle refreshing automatically but we shouldn't care about that here since the steps of this job should be fast. Is that right?

Yes, that's correct. See my note above. The vast majority of our jobs don't take an hour to complete, so this isn't going to be an issue for most cases. Just something to keep in mind.

The best practice though, for the edge case where a single operation might take longer than an hour, is to redesign the step to accept client ID and client secret, and then have the step itself get its own token as needed. Since most actions don't take that long, most actions are still fine to just accept a token - but wanted to lay this out for completeness.

@aaronsteers
Copy link
Contributor

I also put a lot of this extra context in the issue:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aaronsteers aaronsteers aaronsteers approved these changes

@dbgold17 dbgold17 Awaiting requested review from dbgold17

Assignees
No one assigned
Labels
ci
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dbgold17 @aaronsteers