Feat: Global SSH Keys for git provider

[lorenzomigliorero]

What problem will this feature address?

At the moment, every service needs an SSH Key. This is what is most likely going to happen with just 5/6 repos:

Describe the solution you'd like

• Create a new SSH Keys view under /dashboard/settings/server
• Associate an SSH Key to multiple services

Describe alternatives you've considered

.

Additional context

@Siumauricio As usual, I'd like to work on that. Let me know!

[Siumauricio]

Sounds like a good idea, I think we could merge this idea with #98 To be able to reuse source providers

[lorenzomigliorero]

Umh, perhaps they can be developed independently? You can select an SSH Key in the Provider view or associate an SSH Key to a reusable git provider.

Also, what is the benefit of creating a git provider rather than just associating an SSH Key? Fetching the repositories list would be a nice addition, but it changes depending on the provider's APIs, so it's more work.

[Siumauricio]

@lorenzomigliorero Ok, can you detail what will be the implementation and the workflow of this? just to understand more the integration

[lorenzomigliorero]

Sure! Here is how I'm imagining this working:

UX

Under /dashboard/settings/server, there will be another view, SSH Keys. The view will be like this:

• In the project view, by clicking the Lock icon, you'll be able to select an SSH key or generate a new one.

DB

A new sshKey table will be created with these fields:

sshKeyId: z.string(),
key: z.string().min(1),
name: z.string().min(1),
createdAt: z.string()
lastUsedAt: z.string() // updated every time the git clone command uses that key

The application schema will have one relationship with the SSH Key:

customGitSSHKey: one(sshKey) 

When we support reusable git providers, the db structure will look like this: application -> provider -> ssh-key

It's enough adding one sshKey relationship to the provider table, and one provider relationship to the application table.

[Siumauricio]

Sounds good the implementation makes sense @lorenzomigliorero, you are free to do this, thanks!