* Some refactors related repository model
* Move more methods out of repository
* Move repository into models/repo
* Fix test
* Fix test
* some improvements
* Remove unnecessary function
* Fix a panic in NotifyCreateIssueComment (caused by string truncation)
* more unit tests
* refactor
* fix some edge cases
* use SplitStringAtByteN for comment content
The current implementation of checkBranchName is highly inefficient
involving opening the repository, the listing all of the branch names
checking them individually before then using using opened repo to get
the tags.
This PR avoids this by simply walking the references from show-ref
instead of opening the repository (in the nogogit case).
Signed-off-by: Andrew Thornton <art27@cantab.net>
* allways set a message-id on mails
* Add unit tests for mailer & Message-ID
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Refactor install page (db type)
* set correct default DB HOST for different DB TYPE
* remove legacy TiDB from documents
* unify the usage of DB TYPE, in code we only use "mysql". "MySQL" is only shown to users for friendly name.
* Gitea can use TiDB via MySQL protocol
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Fixes#17918. Applies color variables to all ui message on both themes.
The colorization on .segment is a customization not present in fomantic
ui, only used on user/repo/org delete pages.
* Fix loading content history on show more
- Call `initRepoIssueContentHistory` so that the newly loaded issues
also get their content history.
- Resolves#17767
* apply history to show diff too
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
* Fix svg colors in file list table
Turns out this can be fixed by just removing rules. Directory and file
icons have other rules that still make them color correctly.
* tweak color on file icons
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
- Update all JS dependencies to latest versions
- Add new lint rules, enable es2022 eslint parser features
- Disable github/no-then, I feel the rule was too restricting
* Check if column exist before rename if exist, just return with no error
* Also check if errors column exist
* Add comment for migration
* Fix sqlite test
Too many docker users are caught out by the default location for the
app.ini file being environment dependent so that when they docker exec
into the container the gitea commands do not work properly and require
additional -c arguments to correctly pick up the configuration.
This PR simply shadows the gitea binary using variants of the FHS
compatible script to make the command gitea have the default locations
by default.
Fix#14468
Reference #17497
Reference #12082
Reference #8941
... amongst others ...
Replace #17501
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Improve install code to avoid low-level mistakes.
If a user tries to do a re-install in a Gitea database, they gets a warning and double check.
When Gitea runs, it never create empty app.ini automatically.
Also some small (related) refactoring:
* Refactor db.InitEngine related logic make it more clean (especially for the install code)
* Move some i18n strings out from setting.go to make the setting.go can be easily maintained.
* Show errors in CLI code if an incorrect app.ini is used.
* APP_DATA_PATH is created when installing, and checked when starting (no empty directory is created any more).
- Remove blue background and use regular header styling
- Use flexbox on author and signature segments
- Add shield-type icons besides gpg key, replacing icon font icons
- Ensure author and signature line are same height
- Remove erronous green background on arc-green signature line
- Turn signing colors into CSS variables
- Consolidate the two warning states into one
Co-authored-by: zeripath <art27@cantab.net>
This PR registers requests with the process manager and manages hierarchy within the processes.
Git repos are then associated with a context, (usually the request's context) - with sub commands using this context as their base context.
Signed-off-by: Andrew Thornton <art27@cantab.net>
services: provide some services for users, usually use
database (models) modules: provide some basic functions without
database, eg: code parser, etc The major difference is services use
database, while modules don’t.
Signed-off-by: singuliere <singuliere@autistici.org>
