-
Notifications
You must be signed in to change notification settings - Fork 36
feat(integration-github): add repository purpose filtering #373
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.
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
base: 4.x
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| <?php | ||
|
|
||
| declare(strict_types=1); | ||
|
|
||
| use Illuminate\Database\Migrations\Migration; | ||
| use Illuminate\Database\Schema\Blueprint; | ||
| use Illuminate\Support\Facades\Schema; | ||
|
|
||
| return new class extends Migration | ||
| { | ||
| public function up(): void | ||
| { | ||
| Schema::table('github_repositories', static function (Blueprint $table): void { | ||
| $table->string('purpose')->default('contributions'); | ||
| }); | ||
| } | ||
| }; | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -21,6 +21,7 @@ | |
| * @property string $tenant_id | ||
| * @property string $full_name | ||
| * @property bool $enabled | ||
| * @property string $purpose | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shouldn't 'purpose' be an enum rather than a string here?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. |
||
| * @property CarbonInterface|null $last_backfilled_at | ||
| * @property CarbonInterface|null $created_at | ||
| * @property CarbonInterface|null $updated_at | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.