I do have go-1.13.8 installed and get the error message
```
Gitea requires Go 1.13 or greater to build. You can get it at https://golang.org/dl/
```
I do thing that Go 1.14 or greater is actually required
* Exclude the current dump file from the dump
Always prevent the current file from being added to the dump.
Fix#13618
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add skip custom directory option
Signed-off-by: Andrew Thornton <art27@cantab.net>
* placate lint
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Breaking the pipe is a valid way of killing a piped command and any error from
a broken cat-file batch command should be passed back up to the writer any way
therefore specifically logging it is unnecessary.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add files affected by a commit to gitea API -- similar to github
* Add files affected by a commit to gitea API
* Fix stupid error
* Fix other stupid typo
* Generate swagger tmpl
* Comply with convert to git commit refacto
* update swagger docs
* extend test
* format code
* Update integrations/api_repo_git_commits_test.go
* Update modules/convert/git_commit.go
Co-authored-by: Laurent Cahour <laurent.cahour@dont-nod.com>
Co-authored-by: zeripath <art27@cantab.net>
just log if lang is already loaded since we can not reload it
Co-authored-by: jolheiser <john.olheiser@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: zeripath <art27@cantab.net>
* Add Content-Length header to HEAD requests
This change adds the header Content-Length to HEAD HTTP requests.
The previous behaviour was blocking some Windows executables (i.e
bitsadmin.exe) from downloading files hosted in Gitea.
This along with PR #14541, makes the web server compliant with HTTP RFC 2616 which states
"The methods GET and HEAD MUST be supported by all general-purpose servers"
and
"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
This should also respond to issues #8030 and #14532.
* This change adds the header Content-Length to HEAD HTTP requests
Pass the Size of the content as a parameter to ServeData() instead of
calculating it using ioutil.ReadAll(reader) --> this call is dangerous
and can result in a denial of service.
* Add Content-Length header to HEAD requests
Quick fix for imported dependency not used.
* Check if size is positiv int ...
Co-authored-by: zeripath <art27@cantab.net>
REGISTER_MANUAL_CONFIRM is not honored when doing performing an openid registration. The new account is directly accessible.
With this patch, the manual confirm flag gets honored in the same way as a "normal" registration.
* Fix GPG key deletion when user is deleted
Per #14531, deleting a user account will delete the user's GPG keys
from the `gpg_key` table but not from `gpg_key_import`, which causes
an error when creating an account with the same email and attempting
to re-add the same key. This commit deletes all entries from
`gpg_key_import` that match any GPG key IDs belonging to the user.
* Format added code in models/user.go
* Create a new function for listing GPG keys and apply it
Create a new function `listGPGKeys` and replace a previous use
of `ListGPGKeys`. Thanks to @6543 for the patch.
Co-authored-by: Anton Khimich <anton.khimicha@mail.utoronto.ca>
Co-authored-by: 6543 <6543@obermui.de>
Before moving to Chi, HEAD requests were automatically answered by GET
handlers (SetAutoHead(true) from macaron was used).
This Change will restore the previous behaviour.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Migrations currently uses the default Xorm mapper which is
not the same as the mapper Gitea actually uses.
This means that there is a difference between the struct
parsing and mapping to database tables in migrations as
compared to normal Sync2.
This was the cause for the catastrophic problem in v168 -
untagged fields are not mapped in the same way in migrations
as compared to outside of migrations.
This is also likely the cause of some weird subtle failures
in other migrations as any untagged field may not be being
mapped exactly the same way.
This PR suggests that we ensure that the mapper is set at
the start of the migrations code - but also enforces a strict
clean mapper between each migration.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Fix mig 141
* Add Migration to fix it
* update null values to false first
* Alter Table if posible
* use dropTableColumns instead of recreateTable
* MySQL use Alter
* Postgres use Alter
* Update models/migrations/v167.go
* Apply suggestions from code review
* use 2x add col & 2x update & 2x drop col
* let sqlite be the only issue
* use recreate since it just WORKS
