I wanted navigation to the page "first" and the page
"last" of the pages of commits. I discovered this
has already been implemented in one of the templates.
Signed-off-by: Tan Pheng Heong <phtan90@gmail.com>
Modify the call to ping the database to fail gracefully if the
database has not yet been configured by the end user, such as
after a clean install. This allows /healthcheck to return a 200
with a modified status message instead of causing a PANIC.
Signed-off-by: Evan Sherwood <evan@sherwood.io>
* Add size column to attachment
Migrate attachments by calculating file sizes
Signed-off-by: Jonas Franz <info@jonasfranz.software>
* Calculate attachment size on creation
Signed-off-by: Jonas Franz <info@jonasfranz.software>
* Log error instead of returning error
Signed-off-by: Jonas Franz <info@jonasfranz.software>
New Feature:
* Repository struct field for IsFsckEnabled (default true of course)
* Admin Settings section on repo options page, accessible only by
admin users
Possible Enhancements:
* There's no way to force running health checks on all repos
regardless of their IsFsckEnabled setting. This would be useful if
there were an admin API or dashboard button to run fsck immediately.
Issue: https://github.com/go-gitea/gitea/issues/1712
Signed-off-by: Allen Wild <allenwild93@gmail.com>
Why:
* We are using self-signed ssl certificates for internal services, which results in failures when gitea tries to communicate through webhooks with these. We would like to enable gitea to be able to use these certificates without having to build custom docker images.
How
* We add the internal certificates to /usr/local/share/ca-certificates on the host
* We read-only mount /usr/local/share/ca-certificates from the host to /usr/local/share/ca-certificates in the container
* We do a update-ca-certificates in the alpine container before starting gitea
This should have no consequence for users that do not have the need to handle self-signed certificates, as update-ca-certificates should be idempotent.
The choice regarding which forms should or should not trigger a warning
is subjective. I tried to be consistent and not warn about forms that:
- run an action, rather than edit data: search, send an email.
- delete data: a warning about losing data would be confusing
Note that forms on sign-in pages were already ignored (using a selector,
rather than an explicit class on the form element).
Fixes#3698.
* Improve release page ui by adding size
Signed-off-by: Jonas Franz <info@jonasfranz.software>
* Add documentation to a.MustSize()
Signed-off-by: Jonas Franz <info@jonasfranz.software>
* add global code search on explore
* fix bug when no anyone public repos
* change the icon
* fix typo and add UnitTypeCode check for login non-admin user
* fix ui description when no match
* Added checks for protected branches in pull requests
Signed-off-by: Christian Wulff <NChris@posteo.net>
* Moved check for protected branch into new function CheckUserAllowedToMerge
Signed-off-by: Christian Wulff <NChris@posteo.net>
* Removed merge conflict lines from last commit
Signed-off-by: Christian Wulff <NChris@posteo.net>
* Explicit check for error type in ViewIssue
Signed-off-by: Christian Wulff <NChris@posteo.net>
