feat(integration-github): add repository purpose filtering#373
feat(integration-github): add repository purpose filtering#373arthurbazzz wants to merge 3 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughA new 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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.
🧹 Nitpick comments (2)
app-modules/integration-github/src/Webhook/ProjectGithubEvent.php (1)
59-59: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueMagic string
'contributions'duplicated across migration, query, and tests.Centralize in a constant or enum to prevent silent drift between the default value and this filter.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app-modules/integration-github/src/Webhook/ProjectGithubEvent.php` at line 59, The `ProjectGithubEvent` query is using the magic string `contributions` directly, which is duplicated across the codebase and can drift from the default value. Introduce a shared constant or enum for this purpose value in the relevant model/event class and use it in `ProjectGithubEvent` instead of the literal string. Update the migration/default handling and any tests to reference the same symbol so the filter, default, and assertions stay aligned.app-modules/integration-github/database/migrations/2026_06_24_125428_add_purpose_to_github_repositories_table.php (1)
9-17: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMissing
down()makes rollback a silent no-op.Without a
down(),migrate:rollbackwon't drop thepurposecolumn, leaving schema drift.♻️ Add rollback
public function up(): void { Schema::table('github_repositories', static function (Blueprint $table): void { $table->string('purpose')->default('contributions'); }); } + + public function down(): void + { + Schema::table('github_repositories', static function (Blueprint $table): void { + $table->dropColumn('purpose'); + }); + } };🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app-modules/integration-github/database/migrations/2026_06_24_125428_add_purpose_to_github_repositories_table.php` around lines 9 - 17, The migration adds the github_repositories purpose column in the anonymous Migration class but lacks a rollback path, so implement a down() method that reverses the change by dropping purpose from the table. Use the existing up() method and Schema::table pattern in this migration to keep the forward and rollback behavior aligned.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@app-modules/integration-github/database/migrations/2026_06_24_125428_add_purpose_to_github_repositories_table.php`:
- Around line 9-17: The migration adds the github_repositories purpose column in
the anonymous Migration class but lacks a rollback path, so implement a down()
method that reverses the change by dropping purpose from the table. Use the
existing up() method and Schema::table pattern in this migration to keep the
forward and rollback behavior aligned.
In `@app-modules/integration-github/src/Webhook/ProjectGithubEvent.php`:
- Line 59: The `ProjectGithubEvent` query is using the magic string
`contributions` directly, which is duplicated across the codebase and can drift
from the default value. Introduce a shared constant or enum for this purpose
value in the relevant model/event class and use it in `ProjectGithubEvent`
instead of the literal string. Update the migration/default handling and any
tests to reference the same symbol so the filter, default, and assertions stay
aligned.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro
Run ID: aa0e4d01-f06b-45a7-abb5-5bcb14037f64
📒 Files selected for processing (4)
app-modules/integration-github/database/migrations/2026_06_24_125428_add_purpose_to_github_repositories_table.phpapp-modules/integration-github/src/Models/GithubRepository.phpapp-modules/integration-github/src/Webhook/ProjectGithubEvent.phpapp-modules/integration-github/tests/Feature/GithubWebhookTest.php
| * @property string $tenant_id | ||
| * @property string $full_name | ||
| * @property bool $enabled | ||
| * @property string $purpose |
There was a problem hiding this comment.
Shouldn't 'purpose' be an enum rather than a string here?
There was a problem hiding this comment.
I thought about this but i dunno if the "purpose" will grow more or if will remain only this two (contributions | challenge)
So is it better to create a enum?
There was a problem hiding this comment.
So is it better to create a enum?
IMO yes, it will prevent the spread of a possible incorrect string in the system, and at the same time, we will keep it as a strong type, specifying that it will always be only one of these values.
| public function up(): void | ||
| { | ||
| Schema::table('github_repositories', static function (Blueprint $table): void { | ||
| $table->string('purpose')->default('contributions'); | ||
| }); | ||
| } |
There was a problem hiding this comment.
Following the idea of implementing an enum for this value, I would use a nullable string rather than a default value. Then, I would add an extra step to fill it with the default values.
Note
Do not use enums in migrations.
This could be impacted by a change in the future.
It will not be implemented if migration has already occurred; it will only be implemented on new databases.
| public function up(): void | |
| { | |
| Schema::table('github_repositories', static function (Blueprint $table): void { | |
| $table->string('purpose')->default('contributions'); | |
| }); | |
| } | |
| public function up(): void | |
| { | |
| Schema::table('github_repositories', static function (Blueprint $table): void { | |
| $table->string('purpose')->nullable(); | |
| }); | |
| DB::table('github_repositories') | |
| ->update(['purpose' => 'contributions']); | |
| } |
Before applying/implementing this suggestion, I would like to hear from @danielhe4rt and @Clintonrocha98. Default values aren't a problem, but they could be in the future.
3 participants
Contexto
purposeemgithub_repositoriescontributionsdefinido como valor padrãopurpose = challengegerem contribuiçõespurpose = contributionscontributionsechallenge)Closes #344