git settings: Add gitlab project settings + export type#12232
git settings: Add gitlab project settings + export type#12232estib-vega merged 2 commits intomasterfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
github-actions
bot
added
rust
estib-vega
requested review from
Byron,
Caleb-T-Owens and
krlvi
as code owners
There was a problem hiding this comment.
Pull request overview
This PR adds GitLab project ID settings to the git configuration system to support GitLab-specific features. The changes introduce two new configuration fields: gitbutler_gitlab_project_id and gitbutler_gitlab_upstream_project_id.
Changes:
- Added two new GitLab project ID fields to the git config settings (project ID and upstream project ID)
- Replaced the TypeScript
GbConfigclass with the auto-generatedGitConfigSettingstype from Rust - Exported the
GitConfigSettingstype for use across the application
Reviewed changes
Copilot reviewed 4 out of 7 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/core/src/generated/settings/gitConfigSettings.ts | New auto-generated TypeScript type with GitLab fields added |
| packages/core/src/generated/index.ts | Exports the new GitConfigSettings type |
| crates/but-core/tests/core/settings.rs | Updated tests to include new GitLab fields |
| crates/but-core/src/settings.rs | Added constants, struct fields, and initialization for GitLab project IDs with TypeScript export annotations |
| apps/desktop/src/lib/config/gitConfigService.ts | Replaced GbConfig class with imported GitConfigSettings type, updated method signatures |
| apps/desktop/src/lib/ai/service.test.ts | Updated test mock to use GitConfigSettings type |
| Cargo.lock | Minor version bump of thiserror dependency (2.0.17 → 2.0.18) |
estib-vega
force-pushed
the
use-but-gitlab
branch
from
badde06 to
a4b9f62
Compare
- Add the project and upstream project IDs to the git settings - Export the git config type and use it in the git config service
estib-vega
force-pushed
the
use-but-gitlab
branch
from
a4b9f62 to
6b6806a
Compare
I think it's fine to now allow users to provide unreasonable values for it, to save us some trouble with `ts-rs`. Maybe this way we can prevent unnecessary spread of `BStringForFrontend` which clearly is a crutch.
Byron
left a comment
Byron
left a comment
There was a problem hiding this comment.
Thanks a lot!
I added a refactor on top which simplifies the type we store for Gitlab project ids to match what it's storing. That way, everything gets a lot simpler and we don't just proliferate the crutch that is BStringForFrontend.
And seeing these ugly annotations, I was hoping that maybe there is some central place to teach ts-rs basic type mappings, on a project level. So from that point of you, these cfg_attr annotations do exactly what they are supposed to - make us think of ways to have less of them 😁.
In any case, good to go.
| #[serde(rename = "signCommits")] | ||
| pub gitbutler_sign_commits: Option<bool>, | ||
| pub gitbutler_gerrit_mode: Option<bool>, | ||
| #[cfg_attr(feature = "export-ts", ts(type = "string | null"))] |
There was a problem hiding this comment.
While having seen that before, it's strange to me that ts-rs won't do this automatically. Are we sure it' can't turn an option into null - that should be the point of it.
Edit: I think I understand now that the problem is not the Option, the problem is the BStringForFrontend. It would be nice if there was a way to configure ts-rs more centrally, and configure it once.
|
Thanks @Byron! |
2 participants
Uh oh!
There was an error while loading. Please reload this page.