Skip to content

Conversation

@jrparks
Copy link
Contributor

@jrparks jrparks commented Mar 17, 2025

Description

Adds support for Gitea repositories in Dokploy

Changes

  • Added Gitea repository integration

Testing

  • Added a gitea repo, authorized it with gitea, setup a new test project with the gitea repo and successfully deployed it

Additional Notes

  • Had some challenges with the latest canary merges

#1333

@jrparks jrparks requested a review from Siumauricio as a code owner March 17, 2025 21:20
@jrparks
Copy link
Contributor Author

jrparks commented Mar 17, 2025

This was a larger feature then I was expecting. Looking forward to your feedback. Lots of opportunity to stream line the repo code in future changes.

…ross multiple components

- Updated import statements to maintain consistency and clarity.
- Refactored components to enhance readability and organization.
- Ensured proper usage of type imports and removed unnecessary comments.
- Improved user feedback mechanisms in forms and alerts for better user experience.
@Siumauricio
Copy link
Contributor

Siumauricio commented Mar 18, 2025

Hey @jrparks Thank you for this feature, I recommend the following:

  • Drop all the migrations you've created
  • Be sure you have the same migrations as canary branch
  • Generate the migrations again and run the migration:run command and it should work

Edit: I fixed the migrations, just git pull and run the truncate command and then the migration:run command

- Introduced Gitea support by adding necessary database tables and columns.
- Updated enum types to include 'gitea' for source and git provider types.
- Established foreign key relationships between Gitea and application/compose tables.
- Removed obsolete Gitea-related SQL files and updated journal entries for clarity.
Copy link
Contributor

@Siumauricio Siumauricio left a comment

Choose a reason for hiding this comment

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

A few details missing:

  • Gitea for docker compose services
  • Add watch paths for gitea (Applications & Docker-Compose)
  • Revise the webhook deploy to support the watch paths for Gitea Apps
  • Add docs for gitea in the docs repository https://github.com/Dokploy/website

So far I tested the connection and it looks great, works fine, just need to update the steps in the modal, they are not very clear!

Thanks for this feature!

@jrparks
Copy link
Contributor Author

jrparks commented Mar 22, 2025

Docs were added to the https://github.com/Dokploy/website as requested, there is a separate pull request. Let me know if anything further still needs to be addressed.

@jrparks jrparks requested a review from Siumauricio March 22, 2025 19:07
Jason Parks added 2 commits March 22, 2025 13:30
Prevents the brief appearance of dropdown options when opening the Edit Gitea Provider modal by:
- Adding onOpenAutoFocus event handler to prevent automatic focus
- Setting autoFocus={false} on the first input field
- Simplifying component state management

This improves the UI experience by eliminating visual artifacts when the dialog opens.
- Fixed SSH key authentication detection in server-audit.ts
- Added proper handling for prohibit-password and other secure root login options
- Fixed typos in security audit UI labels
- Improved error handling with optional chaining
@jrparks
Copy link
Contributor Author

jrparks commented Mar 22, 2025

I added in a fix for a bug I found in the security audit. I tested that by standing up a new server to validate the setup audit for the ssh section.

- Adjusted GiteaProviderSchema to ensure watchPaths are correctly initialized and validated.
- Refactored SaveGiteaProvider and SaveGiteaProviderCompose components for improved state management and UI consistency.
- Simplified API router methods for Gitea, enhancing readability and error handling.
- Updated database schema and service functions for better clarity and maintainability.
- Removed unnecessary comments and improved logging for better debugging.
…h logic

- Updated Gitea repository cloning to use the remote variant for better consistency.
- Removed unnecessary logging and comments in the token refresh function to streamline the code.
- Improved type handling in the cloneGiteaRepository function for better clarity.
- Added support for handling commit normalization across GitHub, GitLab, and Gitea in the deployment API.
- Implemented a new utility function to determine the provider based on request headers.
- Improved deployment path validation to ensure consistency across different source types.
- Cleaned up the code by removing redundant checks and enhancing readability.
- Eliminated console logging of repositories in the Gitea API router to streamline the code and improve performance.
@jrparks
Copy link
Contributor Author

jrparks commented Mar 23, 2025

Also I made sure the changes work for private Gitea instances when clicking on the "View Repository". We probably need to tweak the other repos to allow for private instances. For sure the gitLab repo.

Remove custom onOpenAutoFocus handler that was preventing proper focus management in the EditGiteaProvider dialog. This fixes the 'Blocked aria-hidden on an element because its descendant retained focus' error by allowing the dialog component to handle focus naturally.
@unleashit
Copy link
Contributor

unleashit commented Mar 23, 2025

Thanks guys for working on this feature, right as I'm discovering Dokploy! Gitea is a much slimmer choice than Gitlab when selfhosting for simple needs.

Quick (maybe a bit tangential, but related) question, as I'm not yet that familiar with Dokploy internals. In the workflow I currently have with Docker Compose services, I'm using the "Git" option to link to a shared Gitea repo with a bunch of different docker compose files. Each are configured as their own Dokploy service, with a custom compose path. This PR will help if it gets the the watch files feature working (since right now, auto deploy causes any push to rebuild all projects). That's great and the main thing. But I also notice that in /etc/dokploy/compose the full repo (including parents of the compose path) is cached for each compose project, even though it's the same repo.

Basically, I'm not sure if that is an issue with the generic git provider, or if the dedicated ones have the same behavior. If the latter, then I can make a separate issue for it if you think it's addressable. It's not a huge problem, but if when using a workflow like mine, the repo contains more than just a few compose files (Ansible roles w files, images, etc.), all that is getting duplicated perhaps many times.

@jrparks
Copy link
Contributor Author

jrparks commented Mar 24, 2025

Thanks guys for working on this feature, right as I'm discovering Dokploy! Gitea is a much slimmer choice than Gitlab when selfhosting for simple needs.

Quick (maybe a bit tangential, but related) question, as I'm not yet that familiar with Dokploy internals. In the workflow I currently have with Docker Compose services, I'm using the "Git" option to link to a shared Gitea repo with a bunch of different docker compose files. Each are configured as their own Dokploy service, with a custom compose path. This PR will help if it gets the the watch files feature working (since right now, auto deploy causes any push to rebuild all projects). That's great and the main thing. But I also notice that in /etc/dokploy/compose the full repo (including parents of the compose path) is cached for each compose project, even though it's the same repo.

Basically, I'm not sure if that is an issue with the generic git provider, or if the dedicated ones have the same behavior. If the latter, then I can make a separate issue for it if you think it's addressable. It's not a huge problem, but if when using a workflow like mine, the repo contains more than just a few compose files (Ansible roles w files, images, etc.), all that is getting duplicated perhaps many times.

Well the entire repo is cloned when the deploy occurs. What you could potentially do is create a different Gitea Provider that is used for the different projects ie. Gitea-P1, Gitea-P2, etc. That could still use the same Gitea Client ID and Client Secret but a hook would not cause it to rebuild everything since the Provider ID's would be different. Probably best to let Siumauricio chime in to see how he wants it handled.

@unleashit
Copy link
Contributor

@jrparks thanks, I wasn't sure if caching the full repo (regardless of the docker compose path) was something all the providers did, which is why I chimed in here. I guess I may not be an average Dokploy user, but it would be nice if tools like Dokploy, Coolify, etc. would make a more gitops / declarative workflow easier (otherwise it's much harder to move, change or recover). I think what I'll probably do is split off my Dokploy projects into their own repo since it would be a lot slimmer and less of a big deal to duplicate in /etc/dokploy. As long as watch files is working, at least in theory I think I can get it all to live nicely by adding the path in each service. Gitea will still call all hooks every time pushed to master, but Dokploy (theoretically,, we'll see!) should only deploy for that service if files were changed in the watch path.

@jrparks
Copy link
Contributor Author

jrparks commented Mar 24, 2025

@jrparks thanks, I wasn't sure if caching the full repo (regardless of the docker compose path) was something all the providers did, which is why I chimed in here. I guess I may not be an average Dokploy user, but it would be nice if tools like Dokploy, Coolify, etc. would make a more gitops / declarative workflow easier (otherwise it's much harder to move, change or recover). I think what I'll probably do is split off my Dokploy projects into their own repo since it would be a lot slimmer and less of a big deal to duplicate in /etc/dokploy. As long as watch files is working, at least in theory I think I can get it all to live nicely by adding the path in each service. Gitea will still call all hooks every time pushed to master, but Dokploy (theoretically,, we'll see!) should only deploy for that service if files were changed in the watch path.

Yes I agree with your suggestion. Please go ahead an open a follow up request and it can be discussed more broadly as it really is something all repos would benefit from, probably needs a little architectural session to iron out deets. I just volunteered some time to help out with the Gitea Feature along with some minor bug improvements to make Dokploy even more amazing.

@jrparks jrparks closed this Mar 24, 2025
@jrparks jrparks reopened this Mar 24, 2025
@unleashit
Copy link
Contributor

I just volunteered some time to help out with the Gitea Feature along with some minor bug improvements to make Dokploy even more amazing.

And very appreciated indeed! Once I've had a chance to work with Dokploy some more and have a chance to think a little better about what in particular to suggest (would probably involve moving some config stuff from the DB and into the file system... OR allow some sort of general import/export of metadata) I will. I'm personally looking at a handful of tools for personal projects (not making any money on this stuff), but once I'm familiar and getting use out of something I tend to roll up my sleeves a little when I can.

@jrparks jrparks requested a review from Siumauricio March 25, 2025 16:39
@Siumauricio
Copy link
Contributor

@jrparks Check this issue:

Screen.Recording.2025-03-26.at.1.26.49.AM.mov

@jrparks
Copy link
Contributor Author

jrparks commented Mar 27, 2025

Should be good to review again.

@jrparks jrparks requested a review from Siumauricio March 27, 2025 21:29
…te related schemas. Add new fields for gitea repository details in application tests and components.
…ring logic and ensure Gitea integration is fully functional with updated tab and content handling.
…ository URL display and enhance user experience with a view link for existing repositories.
…ng of the compose file display by removing unnecessary null check and ensuring consistent layout.
…heck and related UI elements to streamline the code and improve readability.
Copy link
Contributor

@Siumauricio Siumauricio left a comment

Choose a reason for hiding this comment

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

Thank you!!

@Siumauricio Siumauricio merged commit 930a03d into Dokploy:canary Mar 29, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants