-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Feat/add gitea repo #1523
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
Feat/add gitea repo #1523
Conversation
|
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.
|
Hey @jrparks Thank you for this feature, I recommend the following:
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.
Siumauricio
left a comment
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.
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!
…s display - Enhanced the Gitea provider setup instructions by specifying the navigation path for creating a new OAuth2 application. - Added a blank line for better readability in the Git providers display component.
|
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. |
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
|
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.
|
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.
|
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 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. |
|
@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. |
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 Check this issue: Screen.Recording.2025-03-26.at.1.26.49.AM.mov |
apps/dokploy/components/dashboard/compose/general/show-converted-compose.tsx
Outdated
Show resolved
Hide resolved
|
Should be good to review again. |
…te related schemas. Add new fields for gitea repository details in application tests and components.
…n and update journal with new version
…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.
Siumauricio
left a comment
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.
Thank you!!
Description
Adds support for Gitea repositories in Dokploy
Changes
Testing
Additional Notes
#1333