* Change tab width for .go files to 4
I thing 8-wide tabs are kind of archaic and inconsisten with template
files which already use 4-wide.
Also did some misc cleanups in the .editorconfig files.
* add css
Co-authored-by: Lauris BH <lauris@nix.lv>
* Allow all members of private orgs to see public repos
Fix#10144
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update models/repo_list.go
Co-authored-by: Lauris BH <lauris@nix.lv>
* Refactor Cron and merge dashboard tasks
* Merge Cron and Dashboard tasks
* Make every cron task report a system notice on completion
* Refactor the creation of these tasks
* Ensure that execution counts of tasks is correct
* Allow cron tasks to be started from the cron page
* golangci-lint fixes
* Enforce that only one task with the same name can be registered
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fix name check
Signed-off-by: Andrew Thornton <art27@cantab.net>
* as per @guillep2k
* as per @lafriks
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add git.CommandContext variants
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Add archived options to SearchRepository
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add only-private search
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add filter options and paging to dashboard repository page
Signed-off-by: Andrew Thornton <art27@cantab.net>
* swagger generate
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fix-swagger-again
Signed-off-by: Andrew Thornton <art27@cantab.net>
* as per @mrsdizzie also remember state
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
Currently you can see a list of commit history for wiki pages but aren't able to view the commit diff itself. This adds the feature to view an individual commit to a wiki repo.
Closes#8999
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Better styling for code review comment textarea
* align tabular menu with textarea
* border around active tab instead of textarea
* border radius
* use .28571429rem
* Allow log.xxx.default to set logging settings for the default logger only
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update modules/setting/log.go
* as per @silverwind add some documentation
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Handle panics in graceful goroutines
Adds a some deferred functions to handle panics in graceful goroutines
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Handle panic in webhook.Deliver
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Handle panic in mirror.syncMirror
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* docs: update 'Testing redux' in CONTRIBUTING.md
try simplfy it to make it more easy for contributor to follow it to
test their work by themselves.
Signed-off-by: a1012112796 <1012112796@qq.com>
* align help message strings
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Properly generate ref URLs
Tags used to not generate correct URLs (src/branch/tags/1.0.0 instead of
src/tags/1.0.0).
Also cleans up some code around it with the created helper functions.
* Fix formatting and create migration
* Add copyright head to utils_test
* Use a raw query for the ref migration
* Remove semicolon
* Quote column and table names in migration SQL
* Change || to CONCAT, since MSSQL does not support ||
* Make migration engine aware
* Add missing import
* Move ref EndName and URL to the issue service
* Fix tests
* Add test for commit refs
* Update issue.go
* Use the right command for building JavaScript bundles
* Prepare for merge
* Check for refs/* before prepending in migration
* Update services/issue/issue_test.go
* Update modules/git/utils_test.go
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: techknowlogick <matti@mdranta.net>
* Switch code editor to Monaco
This switches out CodeMirror for Monaco which is based on the same code
base as VS code and should work pretty similar to it.
It does add a few async chunks, totalling around 10MB to our build. It
currently supports around 65 languages and in the default configuration,
each language would emit one ugly [number].js chunk, so I opted to
combine them all into a single file for now.
CodeMirror is still being used under the hood by SimpleMDE so it can not
be removed yet.
* inline editorconfig, fix diff, use for markdown, remove more dead code
* refactors, remove jquery usage
* use tab_width
* fix intellisense
* rename function for clarity
* misc tweaks, enable webpack progress display
* only use --progress on dev build
* remove useless borders in arc-green
* fix typo
* remove obsolete comment
* small refactor
* fix file creation and various refactors
* unset useTabStops too when no editorconfig
* small refactor
* disable webpack's [big] warnings
* remove useless await
* fix dark theme check
* rename chunk to 'monaco'
* add to .gitignore and delete webpack dest before build
* increase editor height
* support more editorconfig properties
* remove empty element filter
* rename
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Go template's `{{if ...}}` does not shortcut its tests therefore it is
possible to cause a NPE unless you separate ifs into two.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Fomantic-ui's action button syntax requires that the button is
the next sibling of the input it is attached to and that they
are both children of a div.action.
Fix#11375
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Allow compare page to look up base, head, own-fork, forkbase-of-head
Signed-off-by: Andrew Thornton <art27@cantab.net>
* as per @guillep2k
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update routers/repo/compare.go
* as per @guillep2k
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Rationalise the names a little
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Rationalise the names a little (2)
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Fix 500 with fork of fork
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Prevent 500 on compare different trees
Signed-off-by: Andrew Thornton <art27@cantab.net>
* dotdotdot is perfectly valid in both usernames and repo names
Signed-off-by: Andrew Thornton <art27@cantab.net>
* ensure we can set the head and base repos too
Signed-off-by: Andrew Thornton <art27@cantab.net>
* ensure we can set the head and base repos too (2)
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fix lint
Signed-off-by: Andrew Thornton <art27@cantab.net>
* only set headRepo == baseRepo if isSameRepo
Signed-off-by: Andrew Thornton <art27@cantab.net>
Introduced by b57a735 via removal of jQuery-Migrate.
This PR changes usage of .success on jqXHR to .done.
Fixes#11228 and few other places, such as removal of code comments.
* Correctly set the organization num repos
Correctly set the organization num repos to the number of
accessible repos for the user
Fix#11194
Signed-off-by: Andrew Thornton <art27@cantab.net>
* as per @lunny
Signed-off-by: Andrew Thornton <art27@cantab.net>
* attempt to fix mssql
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update models/user.go
* Explicit columns
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add test and fix 0 counted orgs
Signed-off-by: Andrew Thornton <art27@cantab.net>
* remove orgname from api
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Allow Git ref for /repos/{owner}/{repo}/git/commits/{sha}
* Consolidate API for getting single commit
* Fix tests and do it differently
Co-authored-by: zeripath <art27@cantab.net>
* Initial support of end Range header option in lfs
* Allow end range option to be unspecified
* Declare toByte for consistency
* Factor out content encoding tests from doLfs
This is so Range tests could still use doLfs but without repeating
not related tests
* Add Range header test
* implemented extraHeader
* parametrized expectedStatus
* Add more test cases of Range header
* Fix S1030: should use resp.Body.String()
* Add more tests for edge cases
* Fix tests
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: zeripath <art27@cantab.net>
* Set background of openIDConnect logo to white in arc-green theme
* Fixed linting off arc-green theme
Signed-off-by: Leo Maroni <git@em0lar.de>
* Revert changes of first commit (white background) and replaced the image
* Updated openid_connect (part 2)
* Update public/img/auth/openid_connect.svg
Now in one line
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
If user create pull review through api but not set CommitID,
I think it's necessary to use last headCommitID as default seting,
or this review will be considered as stale review which is wrong
Signed-off-by: a1012112796 <1012112796@qq.com>
There is a potential memory leak in `Workerpool` due to the intricacies of
`time.Timer` stopping.
Whenever a `time.Timer` is `Stop`ped its channel must be cleared using a
`select` if the result of the `Stop()` is `false`.
Unfortunately in `Workerpool` these were checked the wrong way round.
However, there were a few other places that were not being checked.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* split some words from template
* split some words from template
* add " " to mustache expression
* split some words from template
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Manage port in submodule refurl
Fix#11304
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fix lint
Signed-off-by: Andrew Thornton <art27@cantab.net>
* URLJoin is causes a cyclic dependency and possibly isn't what what we want anyway
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Protect against leading .. in scp syntax
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
prevent double entries in results of GetOrgsCanCreateRepoByUserID
I first try to only add GroupBy directly but xorm return broken user objects ...
... solution was to just query related UserIDs(OrgIDs) first and return OrgUsers based on this IDs
close#11258
Co-authored-by: zeripath <art27@cantab.net>
Although default branch is not offered for deletion in the templates, we need to prevent it both at the router level and in the pre-receive hook.
Co-authored-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
There is an unfortunate signature change with the api.Context
NotFound function; whereas the normal modules/context/Context
NotFound function requires an error or nil, the api.Context
variant will panic with an NPE if a nil is provided.
This PR will allow api.Context.NotFound to tolerate a being
passed a nil.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
That's because many notic have more than one lines. So I think
pre is more better to used in here than p
Signed-off-by: a1012112796 <1012112796@qq.com>
* routers: make /compare route available to unauthenticated users
Remove some bits of the compare interface if the user isn't signed in.
Notably, they don't need to see the "New Pull Request" button box nor the
hidden form that would fail to submit due to the POST request continuing to
require proper privileges.
Follow-up commits will improve the UI a bit around this, removing some
"Pull Request" verbiage in favor of "Compare."
* ui: home: show "compare" button for unauthenticated users
This change requires pulling in the BaseRepo unconditionally and
recording if the pull request is in-fact not allowed
(.PullRequestCtx.Allowed). If the user isn't allowed to create a pull
request, either because this isn't a fork or same-fork branch PRs aren't
allowed, then we'll name the button "Compare" instead of "Pull Request."
* ui: branch list: use the new Compare language when available
When viewing the branch listing as an unauthenticated user, you'll get
"Pull Request" buttons. use the new "Compare" verbiage instead, which
matches GitHub behavior when you can't issue a pull request from the
branches.
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
In the /install form, the value for SSH Server Domain is taken form the DOMAIN variable
and overwrites SSH_DOMAIN environment variable set the first time if nothing done
Co-authored-by: Adrian POIGET <adrian.poiget@viveris.fr>
* Add test
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Restore checkbox rendering and prevent poor sanitization of spans
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Also fix preview context
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Also fix preview context
Signed-off-by: Andrew Thornton <art27@cantab.net>
Previously, this required authentication, but there's not actually
any privileged information on this page. Move the endpoint out of
the group that requires sign-in. It still requires the ability to
read issues and pull requests, so private repositories (for instance)
will not be exposed.
Fixes#10312Fixes#11233
This is a boolean flag; simply checking if it's set isn't enough, we must check the value as well.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Make sure that sendmail processes register with the process manager
* Provide a timeout for these (initially of 5 minutes)
* Add configurable value and tie in to documentation
* Tie in to the admin config page.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Now that emojify.js has been removed, get rid of all instances of has-emoji class that was only used for that. Support for rendering shortcodes should remain in all of these places so it should still work the same.
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lauris BH <lauris@nix.lv>
Not all dumps need to include the logs, in a similar vain to not all dumps
needing to include repositories; these may be subject to different backup
mechanisms/constraints. Add a simple option to let them be excluded from the
dump to simplify workflows that need to exclude them or not collect in the
first place.
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: zeripath <art27@cantab.net>
* Fix creation of Org repos
Fix go-gitea#9269
* Change variable name to appease linter
* Update PR with suggestions
Add a note for user.CanCreateRepo() about failure assumptions
Change repo.create help message
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Allow emoji short code in labels
As title, turn :alias: type short code into emojis when rendering labels to match previous behavior
* Update models/issue_label.go
Co-Authored-By: John Olheiser <john.olheiser@gmail.com>
* render text in templates not code
* remove has-emoji class
🧙♀️
* fix new issue form
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Don't allow registration via the web form, when AllowOnlyExternalRegistration is True
* Show Disabled Registration message if DisableRegistration or AllowOnlyExternalRegistration options are true
In #9888, it was reported that my earlier pull request #9075 didn't quite function as expected. I was quite hopeful the `ValuesWithShadow()` worked as expected (and, I thought my testing showed it did) but I guess not. @zeripath proposed an alternative syntax which I like:
```ini
[markup.sanitizer.1]
ELEMENT=a
ALLOW_ATTR=target
REGEXP=something
[markup.sanitizer.2]
ELEMENT=a
ALLOW_ATTR=target
REGEXP=something
```
This was quite easy to adopt into the existing code. I've done so in a semi-backwards-compatible manner:
- The value from `.Value()` is used for each element.
- We parse `[markup.sanitizer]` and all `[markup.sanitizer.*]` sections and add them as rules.
This means that existing configs will load one rule (not all rules). It also means people can use string identifiers (`[markup.sanitiser.KaTeX]`) if they prefer, instead of numbered ones.
Co-authored-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Support unicode emojis and remove emojify.js
This PR replaces all use of emojify.js and adds unicode emoji support to various areas of gitea.
This works in a few ways:
First it adds emoji parsing support into gitea itself. This allows us to
* Render emojis from valid alias (😄)
* Detect unicode emojis and let us put them in their own class with proper aria-labels and styling
* Easily allow for custom "emoji"
* Support all emoji rendering and features without javascript
* Uses plain unicode and lets the system render in appropriate emoji font
* Doesn't leave us relying on external sources for updates/fixes/features
That same list of emoji is also used to create a json file which replaces the part of emojify.js that populates the emoji search tribute. This file is about 35KB with GZIP turned on and I've set it to load after the page renders to not hinder page load time (and this removes loading emojify.js also)
For custom "emoji" it uses a pretty simple scheme of just looking for /emojis/img/name.png where name is something a user has put in the "allowed reactions" setting we already have. The gitea reaction that was previously hard coded into a forked copy of emojify.js is included and works as a custom reaction under this method.
The emoji data sourced here is from https://github.com/github/gemoji which is the gem library Github uses for their emoji rendering (and a data source for other sites). So we should be able to easily render any emoji and :alias: that Github can, removing any errors from migrated content. They also update it as well, so we can sync when there are new unicode emoji lists released.
I've included a slimmed down and slightly modified forked copy of https://github.com/knq/emoji to make up our own emoji module. The code is pretty straight forward and again allows us to have a lot of flexibility in what happens.
I had seen a few comments about performance in some of the other threads if we render this ourselves, but there doesn't seem to be any issue here. In a test it can parse, convert, and render 1,000 emojis inside of a large markdown table in about 100ms on my laptop (which is many more emojis than will ever be in any normal issue). This also prevents any flickering and other weirdness from using javascript to render some things while using go for others.
Not included here are image fall back URLS. I don't really think they are necessary for anything new being written in 2020. However, managing the emoji ourselves would allow us to add these as a feature later on if it seems necessary.
Fixes: https://github.com/go-gitea/gitea/issues/9182
Fixes: https://github.com/go-gitea/gitea/issues/8974
Fixes: https://github.com/go-gitea/gitea/issues/8953
Fixes: https://github.com/go-gitea/gitea/issues/6628
Fixes: https://github.com/go-gitea/gitea/issues/5130
* add new shared function emojiHTML
* don't increase emoji size in issue title
* Update templates/repo/issue/view_content/add_reaction.tmpl
Co-Authored-By: 6543 <6543@obermui.de>
* Support for emoji rendering in various templates
* Render code and review comments as they should be
* Better way to handle mail subjects
* insert unicode from tribute selection
* Add template helper for plain text when needed
* Use existing replace function I forgot about
* Don't include emoji greater than Unicode Version 12
Only include emoji and aliases in JSON
* Update build/generate-emoji.go
* Tweak regex slightly to really match everything including random invisible characters. Run tests for every emoji we have
* final updates
* code review
* code review
* hard code gitea custom emoji to match previous behavior
* Update .eslintrc
Co-Authored-By: silverwind <me@silverwind.io>
* disable preempt
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
As seen in trouble shooting #11032 the new feature of Go 1.14 is causing several second delays in startup in certain situations. Debugging shows it spending several seconds handling SIGURG commands during init:
```
6922:04:51.984234 trace init() ./modules/queue/unique_queue_wrapped.go
remote: ) = 69 <0.000012>
remote: [pid 15984] 22:04:51 write(1, "\ttime taken: 236.761\302\265s\n\n", 25 time taken: 236.761µs
remote:
remote: ) = 25 <0.000011>
remote: [pid 15984] 22:04:51 --- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=15984, si_uid=0} ---
remote: [pid 15984] 22:04:52 --- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=15984, si_uid=0} ---
remote: [pid 15984] 22:04:52 --- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=15984, si_uid=0} ---
```
This causes up to 20 seconds added to a push in some cases as it happens for each call of the gitea hook command. This is likely the cause of #10661 as well and would start to effect users once we release 1.12 which would be the first release compiled with Go 1.14. I suspect this is just a slight issue with the upstream implementatation as there have been a few very similar bugs fixed and reported:
https://github.com/golang/go/issues/37741https://github.com/golang/go/issues/37942
We should revisit this in the future and see if a newer version of Go has solved it, but for now disable this option in the environment that gitea hook runs in to avoid it.
Reduce the code duplication in the PushCreate test and switch
to a declarative format.
* Instead of explicitly creating the repository re-use functions from the other declarative tests and add comments
* Ensure that the test repository is deleted at the end of test
* Slightly reorder the sub-tests
Also reduce the code duplication in MergeFork and add some comments there too and make doGitCloneFail be self-contained.
Signed-off-by: Andrew Thornton art27@cantab.net
* switch to use pseudorandom generator and stop cloning in pushcreate
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add some logging of BranchProtectPRMerge
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Stop running prepareTestEnv so often for TestAPIGetBranch
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Prevent panic during wrappedConn close at hammertime
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update modules/graceful/server.go
* Fix extraneous debug in goldmark.go
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Fix checkbox rendering
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Normalize checkbox rendering
Signed-off-by: Andrew Thornton <art27@cantab.net>
* set the checkboxes to readonly instead of disabled
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Add control for the rendering of the frontmatter
* Add control to include a TOC
* Add control to set language - allows control of ToC header and CJK glyph choice.
Signed-off-by: Andrew Thornton art27@cantab.net
* as title, do same changs on action view with #10737
* chage default icon from "invalid type" to "question" , because "invalid type" is not a meaningfull icon type
Signed-off-by: a1012112796 <1012112796@qq.com>
* Use AJAX for notifications table
Signed-off-by: Andrew Thornton <art27@cantab.net>
* move to separate js
Signed-off-by: Andrew Thornton <art27@cantab.net>
* placate golangci-lint
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add autoupdating notification count
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Fix wipeall
Signed-off-by: Andrew Thornton <art27@cantab.net>
* placate tests
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Try hidden
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Try hide and hidden
Signed-off-by: Andrew Thornton <art27@cantab.net>
* More auto-update improvements
Only run checker on pages that have a count
Change starting checker to 10s with a back-off to 60s if there is no change
Signed-off-by: Andrew Thornton <art27@cantab.net>
* string comparison!
Signed-off-by: Andrew Thornton <art27@cantab.net>
* as per @silverwind
Signed-off-by: Andrew Thornton <art27@cantab.net>
* add configurability as per @6543
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add documentation as per @6543
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Use CSRF header not query
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Further JS improvements
Fix @etzelia update notification table request
Fix @silverwind comments
Co-Authored-By: silverwind <me@silverwind.io>
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Simplify the notification count fns
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: silverwind <me@silverwind.io>
Some OAuth2 providers return quite large structured tokens >32767 bytes.
Gitea currently has a fixed maximum of 32767 bytes for these and
unfortunately due to the convoluted nature of the dependent libraries the
error returned is rather opaque.
Here we manage the error a little better - detecting the rather opaque
github.com/gorilla/securecookie.errEncodedValueTooLong and converting
it to a more readable error.
Further we provide a configurable option to increase the maximum size of
the provided OAuth2 tokens.
Fix#9907
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Improves representation of attachments in issues to a list showing the file name and file size (see #6500 and #6089).
Signed-off-by: Matthias Schoettle <git@mattsch.com>
* Fixes indentation.
Co-authored-by: zeripath <art27@cantab.net>
* First stab at a Gitlab migrations interface.
* Modify JS to show migration for Gitlab
* Properly strip out #gitlab tag from repo name
* Working Gitlab migrations!
Still need to figure out how to hide tokens/etc from showing up in opts.CloneAddr
* Try #2 at trying to hide credentials.
CloneAddr was being used as OriginalURL.
Now passing OriginalURL through from the form and saving it.
* Add go-gitlab dependency
* Vendor go-gitlab
* Use gitlab.BasicAuthClient
Correct CloneURL.
This should be functioning!
Previous commits fixed "Migrated from"
from including the migration credentials.
* Replaced repoPath with repoID globally.
RepoID is grabbed in NewGitlabDownloader
* Logging touchup
* Properly set private repo status.
Properly set milestone deadline time.
Consistently use Gitlab username for 'Name'.
* Add go-gitlab vendor cache
* Fix PR migrations:
- Count of issues is kept to set a non-conflicting PR.ID
- Bool is used to tell whether to fetch Issue or PR comments
* Ensure merged PRs are closed and set with the proper time
* Remove copyright and some commented code
* Rip out '#gitlab' based self-hosted Gitlab support
* Hide given credentials for migrated repos.
CloneAddr was being saved as OriginalURL.
Now passing OriginalURL through from the form and
saving it in it's place
* Use asset.URL directly, no point in parsing.
Opened PRs should fall through to false.
* Fix importing Milestones.
Allow importing using Personal Tokens or anonymous access.
* Fix Gitlab Milestone migration if DueDate isn't set
* Empty Milestone due dates properly return nil, not zero time
* Add GITLAB_READ_TOKEN to drone unit-test step
* Add working gitlab_test.go.
A Personal Access Token, given in env variable GITLAB_READ_TOKEN
is required to run the test.
* Fix linting issues
* Add modified JS files
* Remove pre-build JS files
* Only merged PRs are marged as merged/closed
* Test topics
* Skip test if gitlab is inaccessible
* Grab personal token from username, not password.
Matches Github migration implementation
* Add SetContext() to GitlabDownloader.
* Checking Updated field in Issues.
* Actually fetch Issue Updated time from Gitlab
* Add Gitlab migration GetReviews() stub
* Fix Patch and Clone URLs
* check Updated too
* fix mod
* make vendor with go1.14
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Remove errant third } from account.tmpl
Fix#11128
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Remove errant third curly bracket from pull.tmpl
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update templates/user/settings/account.tmpl
* Add option to use /tmp for test repositories
* Fix exit status
* Add feedback about using tmp repos
Co-authored-by: Guillermo Prandi <guillep2k@users.noreply.github.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* use same process as in routers/repo/branch.go/deleteBranch
* make sure default branch can not be deleted
* remove IsDefaultBranch from UI process - it is worth its own pull
* permissions
Instead of further handling requests to public which causes issues like #11088, immediately terminate requests to directories js, css, fomantic if no file is found which is checked against a hardcoded list. Maybe there is a way to retrieve the top-level entries below public in a dynamic fashion.
I also added fomantic to the reserved usernames and sorted the list.
Fixes: #11088
* Add a way to mark Conversation (code comment) resolved
mark Conversation is a way to mark a Conversation is stale
or be solved. when it's marked as stale, will be hided like
stale. all Pull Request writer , Offical Reviewers and poster
can add or remove Conversation resolved mark.
Signed-off-by: a1012112796 <1012112796@qq.com>
* fix lint
* Apply suggestions from code review
* Add ResolveDoer
* fix ui
Co-Authored-By: Lauris BH <lauris@nix.lv>
Co-Authored-By: 6543 <6543@obermui.de>
* change IsResolved to an function
Add permission check in UpdateResolveConversation
* Apply suggestions from code review
* change return error for permisson check
* add default message for deleted user
* get issue message from comment
* add migration for ``ResolveDoerID`` column
another change:
* block mark pending review as resolved because it's not necessary
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* change button color
* resolve button size
* fix code style
* remove unusefull code
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Fix InsertReleases Nil Insert on Attachments
* FIX "No element on slice when insert" & smal refactor
* again
* impruve
* rm useles newline
* Apply suggestions from code review
Co-Authored-By: zeripath <art27@cantab.net>
* process insert as a whole
Co-authored-by: zeripath <art27@cantab.net>
* Add missing commit states to PR checks template
* Add separate translation strings for warning and error
* Fix failure status string
* Revert accidental change with whitespace
It is possible for misconfigured protected branches to have required status checks that are not in any of the current statuses: Pending, Success, Error, Failure, or Warning - presumably because the CI has not contacted us as yet.
Fix#10636 by adding case: missing StatusChecks when these are missing
Across several files, references to cron.update_migration_post_id are made, although the actual setting is called cron.update_migration_poster_id according to modules/setting/cron.go (10e2f29144/modules/setting/cron.go (L54)).
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* Cache PullRequest Divergence
* only re-calc divergence if AddTestPullRequestTask() is exec
* migrate already open pulls
* finalize
* take care of closed¬-merged+deleted-branch pull requests
* fix nil pointer exeption
Signed-off-by: 6543 <6543@obermui.de>
* try this
* no error its a warn
* init gitea-repositories-meta
* dont use gitDivergence type
* CI.restart()
* CI.restart()
* CI.restart()
* CI.restart()
* check IsUserAllowedToUpdate independend from CommitsBehind
* make sure duplicate token names cannot be used
* add check to api routes too
* add @lunny s suggestion
* fix & don't forget User.ID
* AccessTokenByNameExists() return error too
* unique token for each test
* fix lint
Signed-off-by: 6543 <6543@obermui.de>
Co-authored-by: Lanre Adelowo <yo@lanre.wtf>
This should eliminate page freezes when loading big files/diff.
`highlightBlock` is needed to preserve existing nodes when highlighting
and for that, highlight.js needs access to the DOM API so I added a DOM
implementation to make it work, which adds around 300kB to the output
file size of the lazy-loaded `highlight.js`.
Co-authored-by: Lauris BH <lauris@nix.lv>
* fix some bug about Request review
* fix ``CreateComment`` wrong using ,it will not work when use Sqlite
* fix wrong js click event code , it will send wrong data when it has
many choices
Signed-off-by: a1012112796 <1012112796@qq.com>
* Apply suggestions from code review
Co-Authored-By: Lauris BH <lauris@nix.lv>
* add getReviewerByIssueIDAndUserID
fix wrong conditions check in initIssueComments after #10972
* call CI again
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Add api methods for getting and updating user oauth2 applications.
Signed-off-by: Dan Molik <dan@danmolik.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Update header.tmpl
* Update _repository.less
* Update pull.go
* Update indexer.go
* Update pull.go
* Update pull.go
* Update indexer.go
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
* fix forked repo doesn't have language stat
Thanks the advice from lunny and 6543.
* fix forked repo doesn't have language stat
Modified as suggested by 6543.
* fix forked repo doesn't have language stat
simplify the function.
* fix forked repo doesn't have language stat
update the indexer after the loop
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: Lauris BH <lauris@nix.lv>
* [suggest] change merge strategy: do not check write access if user in merge white list #10935
(cherry picked from commit ba74fc6389dfcad03c273441a49b54e4d38c86ee)
* fix NPE
* Fix cross compile (#10952)
* Fix cross compile
* Add test for cross compile
* Fix drone
* Fix drone
* Also prevent CC environment not to generate
Co-authored-by: zeripath <art27@cantab.net>
* fix merge box icon color bug (#10974)
that because need some space beturn ``text`` and color defines
Signed-off-by: a1012112796 <1012112796@qq.com>
* [skip ci] Updated translations via Crowdin
* Allow X in addition to x in tasks (#10979)
Signed-off-by: Andrew Thornton <art27@cantab.net>
* remove api: merge reqRepoWriter
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: 赵智超 <1012112796@qq.com>
Co-authored-by: GiteaBot <teabot@gitea.io>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* remove a user from being assigned to any issue/PR if (s)he is removed as a collaborator
* fix gender specific comment
* do not remove users that still have access to the repo if they are a member of a team that can access the repo
* add context to errors
* updates
* incorporate review fixes
* Update models/repo_collaboration.go
Co-Authored-By: 6543 <6543@obermui.de>
* Update models/repo_collaboration.go
Co-Authored-By: 6543 <6543@obermui.de>
* Fix Rebase Relict
* Fix & Impruve
* use xorm builder
* all in one session
* generalize reconsiderIssueAssignees
* Only Unwatch if have no access anymore
* prepare for reuse
* Same things if remove User from Team
* fix lint
* let mysql take time to react
* add description
* CI.restart()
* CI.restart()
Co-authored-by: Lanre Adelowo <yo@lanre.wtf>
Co-authored-by: techknowlogick <matti@mdranta.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
Since GNU Make does not allow '/' in the target patterns,
we tranlate the subsequent '.' into '/' for "go test -run".
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* add request review feature in pull request
add a way to notify specific reviewers to review like github , by add or delet a special type
review . The acton is is similar to Assign , so many code reuse the function and items of
Assignee, but the meaning and result is different.
The Permission style is is similar to github, that only writer can add a review request from Reviewers,
but the poster can recall and remove a review request after a reviwer has revied even if he don't have
Write Premission. only manager , the poster and reviewer of a request review can remove it.
The reviewers can be requested to review contain all readers for private repo , for public, contain
all writers and watchers.
The offical Review Request will block merge if Reject can block it.
an other change: add ui otify for Assignees.
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
Signed-off-by: a1012112796 <1012112796@qq.com>
* new change
* add placeholder string
* do some changes follow #10238 to add review requests num on lists also
change icon for review requests to eye
Co-authored-by: Lauris BH <lauris@nix.lv>
* ui: limit managers prohibit themself to login
Because I think it's crazy and not reasonale , that if a user can
prohibit themself to login. so suggest limit this choice on ui
Signed-off-by: a1012112796 <1012112796@qq.com>
* skip self Prohibit Login in post event handle
* fix comment
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add `gitea doctor --list` flag to list the checks that will be run, including those by default
* Add `gitea doctor --run` to run specific checks
* Add `gitea doctor --all` to run all checks
* Add db version checker
* Add non-default recalculate merge bases check/fixer to doctor
* Add hook checker (Fix#9878) and ensure hooks are executable (Fix#6319)
* Fix authorized_keys checker - slight change of functionality here because parsing the command is fragile and we should just check if the authorized_keys file is essentially the same as what gitea would produce. (This is still not perfect as order matters - we should probably just md5sum the two files.)
* Add SCRIPT_TYPE check (Fix#10977)
* Add `gitea doctor --fix` to attempt to fix what is possible to easily fix
* Add `gitea doctor --log-file` to set the log-file, be it a file, stdout or to switch off completely. (Fixes previously undetected bug with certain xorm logging configurations - see @6543 comment.)
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Migrate ActivityHeatmap to Vue SFC
Signed-off-by: Gary Kim <gary@garykim.dev>
* Readd vue compiler alias
Signed-off-by: Gary Kim <gary@garykim.dev>
* Remove unneeded use of v-html
Signed-off-by: Gary Kim <gary@garykim.dev>
Co-authored-by: zeripath <art27@cantab.net>
* Fix cross compile
* Add test for cross compile
* Fix drone
* Fix drone
* Also prevent CC environment not to generate
Co-authored-by: zeripath <art27@cantab.net>
* Prevent support libraries from compiling into Gitea
* Fix tag position
* Fix golangci-lint errors
* Refactor to make it work
Co-authored-by: Guillermo Prandi <guillep2k@users.noreply.github.com>
Now that our minimum required go version is 1.12 we can remove code that disables GO111MODULE globally and turn it on, so each command doesn't need it set specifically.
Also fixes a small bug with make pr that didn't work because GO111MODULE=on wasn't set
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* ui: add more message on sidebar menus
* add title on the menus
* show some message instead of hide choose bar when have nothing to choose
* add simply filter for each menus
* do same changes in mew_form.tmpl
* remove some unusefull comments in mew_form.tmpl
Signed-off-by: a1012112796 <1012112796@qq.com>
* do review suggestions
* add filter message on sidebar filter
* change IsIssueWriter to HasIssuesOrPullsWritePermission
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Fix rebase conflict detection in git 2.26
Git changed the technique used in rebase from
simple apply-patches to use merge. This breaks
our conflict detection code.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* As per @techknowlogick reduce copying
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Generate Diff and Patch direct from Pull head
Fix#10932
Also fix "Empty Diff/Patch File when pull is merged"
Closes#10934
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add tests to ensure that diff does not change
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Ensure diffs and pulls pages work if head branch is deleted too
Signed-off-by: Andrew Thornton <art27@cantab.net>
* change the icon of ApproveReview pr from "eye" to "check" like github
* change the icon of RejectReview pr from "x" to "request-change" like github
* add "-" after "{{" which need to be one line (TODO: may be not change all)
Signed-off-by: a1012112796 <1012112796@qq.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Switch to use a temporary repository instead of adding remotes to the base gitea repository to prevent deadlocking the base gitea repository.
* Add documentation on how to use func **createTemporaryRepo**
* Add organization wide labels
Implement organization wide labels similar to organization wide
webhooks. This lets you create individual labels for organizations that can be used
for all repos under that organization (so being able to reuse the same
label across multiple repos).
This makes it possible for small organizations with many repos to use
labels effectively.
Fixes#7406
* Add migration
* remove comments
* fix tests
* Update options/locale/locale_en-US.ini
Removed unused translation string
* show org labels in issue search label filter
* Use more clear var name
* rename migration after merge from master
* comment typo
* update migration again after rebase with master
* check for orgID <=0 per guillep2k review
* fmt
* Apply suggestions from code review
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
* remove unused code
* Make sure RepoID is 0 when searching orgID per code review
* more changes/code review requests
* More descriptive translation var per code review
* func description/delete comment when issue label deleted instead of hiding it
* remove comment
* only use issues in that repo when calculating number of open issues for org label on repo label page
* Add integration test for IssuesSearch API with labels
* remove unused function
* Update models/issue_label.go
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Use subquery in GetLabelIDsInReposByNames
* Fix tests to use correct orgID
* fix more tests
* IssuesSearch api now uses new BuildLabelNamesIssueIDsCondition. Add a few more tests as well
* update comment for clarity
* Revert previous code change now that we can use the new BuildLabelNamesIssueIDsCondition
* Don't sort repos by date in IssuesSearch API
After much debugging I've found a strange issue where in some cases MySQL will return a different result than other enigines if a query is sorted by a null collumn. For example with our integration test data where we don't set updated_unix in repository fixtures:
SELECT `id`, `owner_id`, `owner_name`, `lower_name`, `name`, `description`, `website`, `original_service_type`, `original_url`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `status`, `is_fork`, `fork_id`, `is_template`, `template_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` ORDER BY updated_unix DESC LIMIT 15 OFFSET 45
Returns different results for MySQL than other engines. However, the similar query:
SELECT `id`, `owner_id`, `owner_name`, `lower_name`, `name`, `description`, `website`, `original_service_type`, `original_url`, `default_branch`, `num_watches`, `num_stars`, `num_forks`, `num_issues`, `num_closed_issues`, `num_pulls`, `num_closed_pulls`, `num_milestones`, `num_closed_milestones`, `is_private`, `is_empty`, `is_archived`, `is_mirror`, `status`, `is_fork`, `fork_id`, `is_template`, `template_id`, `size`, `is_fsck_enabled`, `close_issues_via_commit_in_any_branch`, `topics`, `avatar`, `created_unix`, `updated_unix` FROM `repository` ORDER BY updated_unix DESC LIMIT 15 OFFSET 30
Returns the same results.
This causes integration tests to fail on MySQL in certain cases but would never show up in a real installation. Since this API call always returns issues based on the optionally provided repo_priority_id or the issueID itself, there is no change to results by changing the repo sorting method used to get ids earlier in the function.
* linter is back!
* code review
* remove now unused option
* Fix newline at end of files
* more unused code
* update to master
* check for matching ids before query
* Update models/issue_label.go
Co-Authored-By: 6543 <6543@obermui.de>
* Update models/issue_label.go
* update comments
* Update routers/org/setting.go
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: 6543 <6543@obermui.de>
* Fix broken merge base migration v128 for merged PR
* Allow PRs with deleted base branches to still show diff
* as per @lunny
Co-authored-by: Lauris BH <lauris@nix.lv>
* Fix milestones too many SQL variables bug
* Fix test
* Don't display repositories with no milestone and fix tests
* Remove unused code and add some comments
* upgrade golangci-lint to 1.24.0 to allow go 1.14 compatibility
* fix golangci-lint errors
* make make golangci-lint work when out of go-path
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Split dashboard elements into separate template files
No code change just Move Heatmap and Repo list/search into separate
template files (like feeds and navbar already are). This will let a
user more easily replace dashboard.tmpl without regularly becoming
out of sync with fixes or changes to the actual code.
Fixes#10870
* End file with an empty line
Co-authored-by: zeripath <art27@cantab.net>
* Add IIS Reverse Proxy documentation
@mahdiit in #10748 described how to set up IIS as a reverse proxy. This
PR adds these to our documentation.
Close#10748
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update docs/content/doc/usage/reverse-proxies.en-us.md
Co-Authored-By: mrsdizzie <info@mrsdizzie.com>
Co-authored-by: mrsdizzie <info@mrsdizzie.com>
Unfortunately there appears to be potential race with notifications
being set before the associated issue has been committed.
This PR adds protection in to the notifications list to log any failures
and remove these notifications from the display.
References #10815 - and prevents the panic but does not completely fix
this.
Signed-off-by: Andrew Thornton <art27@cantab.net>
- Added 'lint', 'lint-frontend', 'lint-backend' targets
- Added 'lint-frontend', 'lint-backend' ci steps and restructure the
'compliance' pipeline to have a clear separation between frontend and
backend and use parallelism where possible. Also, the main build
pipelines now depend on 'compliance' so they will skip if it fails.
- Added dependencies on ci steps so they skip when 'compliance' fails
- Moved JS linters to devDependencies
- Removed deprecated 'js' and 'css' targets
* Use ErrKeyUnableToVerify if fail to calc fingerprint in ssh-keygen
Fix#3985
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Pass up the unable to verify
Because the assigness has been loaded in
compare.go 416:
RetrieveRepoMetas(ctx, ctx.Repo.Repository, true)
then
issue.go 381
RetrieveRepoMilestonesAndAssignees(ctx, repo)
then
issue.go 361 -- 365 , they are load assignees
So the code on compare.go 425 -- 427 is double work,
and which is the reason of #10853
Signed-off-by: a1012112796 <1012112796@qq.com>
* Add Matrix webhook
Signed-off-by: Till Faelligen <tfaelligen@gmail.com>
* Add template and related translations for Matrix hook
Signed-off-by: Till Faelligen <tfaelligen@gmail.com>
* Add actual webhook routes and form
Signed-off-by: Till Faelligen <tfaelligen@gmail.com>
* Add missing file
Signed-off-by: Till Faelligen <tfaelligen@gmail.com>
* Update modules/webhook/matrix_test.go
* Use stricter regex to replace URLs
Signed-off-by: Till Faelligen <tfaelligen@gmail.com>
* Escape url and text
Signed-off-by: Till Faelligen <tfaelligen@gmail.com>
* Remove unnecessary whitespace
* Fix copy and paste mistake
Co-Authored-By: Tulir Asokan <tulir@maunium.net>
* Fix indention inconsistency
* Use Authorization header instead of url parameter
* Add raw commit information to webhook
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Tulir Asokan <tulir@maunium.net>
* Handle push rejections and push out-of-date in branch creation and
file upload.
* Remove the duplicated sanitize from services/pull/merge
* Move the errors Err(Merge)PushOutOfDate and ErrPushRejected to
modules/git
* Handle errors better in the upload file dialogs
Fix#10460
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* make admin auth list formatting configurable
Signed-off-by: Andrew Thornton <art27@cantab.net>
* As per @guillep2k
Signed-off-by: Andrew Thornton <art27@cantab.net>
speed up page generation by making avatar lookup occur at the browser
not at page generation
* Protect against evil email address ".."
* hash the complete email address
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-Authored-By: Lauris BH <lauris@nix.lv>
Annoyingly goldmarks SetAttributeString requires that
the value of the attribute is still a []byte but does
not make it clear in the documentation.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Option to set default branch at repository creation
* Handle template repos with non-default master branch
* Add DefaultBranch handling on creation to API
Fix#9542
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Simplify grep regexp to be more compatible
The new expression also works with the BSD implementation of grep. Also,
I believe the expression did not work consistently for all possible
version numers, for example a two digit patch version would not have
been matched.
* Fix quote
* Allow for two and three part version numbers
* Select one, two and three part version numbers, reject amd64
* Also allow one to three parts for node version
* Use JS code to print node verion in correct format
* Avoid grep altogether
* Handle go1.14beta1 as well.
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
- move all JS build dependencies to 'dependencies'
- update all JS dependencies
Reason for this is that npm will only install 'dependencies' when under
the effect of NODE_ENV=production which may be present on some build
systems.
Linters currently need to be depdendencies because we run linting as
part of the build step, but I plan to move them to a separate 'lint'
target which means they can move to devDependencies then.
Fixes: https://github.com/go-gitea/gitea/pull/10761
- update to latest version and move to npm
- adapt for api changes and css class rename
- add specificity to arc-green rules as dependency css now loads later
- use imports-loader to make it load correctly
- fix some wrong paths in librejs
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
reason:
If user can't choose the Assignees labels and Milestone It's
not usefull to show a gear label , and it It will mislead the
user into thinking that it's a BUG rather than thy don't have
permission to chosse them.
Signed-off-by: a1012112796 <1012112796@qq.com>
Result of `make npm-update`. Only notable change is that `updates` now
requires Node 10 and has been changed to a bundle, so its dependencies
are now no longer installed.
* Add more logging in the LFS server
Adds more logging in the LFS server and stops sending internal server
error information to the client
* Add LFS Lock cursor implementation
* Simplify Claims in LFS and remove the float64 casts
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Fix panic in API pulls when headbranch does not exist
* refix other reference to plumbing.ErrReferenceNotFound
Signed-off-by: Andrew Thornton <art27@cantab.net>
- Use a whitelist-based approach to find *.go files so we can use
standard find syntax. Also included is a change that files no
longer pass a leading './' which should help performance further.
- Instead of running `find` multiple times in make because of the
lazy evaluation, run it only once and add the bindata files when
the bindata tag is present
This is another huge speedup on my machine of around 2000%.
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Create system webhook column (and migration)
* Create system webhook DB methods
Based on the default webhook ones
* Modify router to handle system webhooks and default ones
* Remove old unused admin nav template
* Adjust orgRepoCtx to differentiate system and default webhook URLs
* Assign IsSystemWebhook when creating webhooks
* Correctly use booleans for IsSystemWebhook
* Use system webhooks when preparing webhooks for payload
* Add UI and locale changes
* Use router params to differentiate admin hook pages
* Fix deleting admin webhooks and rename method
* Add clarity to webhook docs
* Revert "Remove old unused admin nav template"
This reverts commit 191a20a738.
* Rename WebHooksNewPost to GiteaHooksNewPost for clarity
* Reintroduce blank line lost during merge conflict
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Fix task-list checkbox styling
The pandoc renderer will append the class "task-list" to the ul element
wrapping a li with one or more check-boxes. This allows us to select for
them, removing their list-style-type property. However, goldmark and the
gfm spec doesn't specify the "task-list" class name, so we can't use
that to fix the issue there.
Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
* Update to goldmark v1.1.25
This version adds the missing space after a checkbox.
Resolves: #9656
Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Also adjusted other version mentions so go version is always mentioned
as major.minor and node only as major.
Co-authored-by: silverwind <me@silverwind.io>
* Display pull request head branch even the branch deleted or repository deleted
* Merge getHeadRepo/loadHeadRepo and getBaseRepo/loadBaseRepo on pull and fill repo when pr.Issue.Repo is available
* retrieve sha from pull head when pull request branch deleted and fix tests
* Fix test
* Ensure MustHeadRepoName returns empty string if no head repo
Co-authored-by: zeripath <art27@cantab.net>
* Speed up make
- stop `find` from venturing into node_modules and other directories
that do not contain *.go files
- only run `find` once for *.go files
- move image tempdir generation to that task
- rename GOFILES to GO_SOURCES_OWN for consistency and to indicate that
vendor files are not included
- pre-resolve FOMANTIC_SOURCES
* exclude more
Co-authored-by: Lauris BH <lauris@nix.lv>
Unfortunately the fix in #10511 was slightly incorrect and placed the
detail box at one level too far out.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* adding search capability to user's issues dashboard
* global issue search
* placement of search bar on issues dashboard
* fixed some bugs in the issue dashboard search
* added unit test because IssueIDs option was added to UserIssueStatsOptions
* some renaming of fields in the issue dashboard code to be more clear; also trying to fix issue of searching the right repos based on the filter
* added unit test fro GetRepoIDsForIssuesOptions; fixed search lost on pagination; using shown issue status for open/close count; removed some debugging
* fix issue with all count showing incorrectly
* removed todo comment left in by mistake
* typo pulling wrong count
* fxied all count being off when selecting repositories
* setting the opts.IsClosed after pulling repos to search, this is done so that the list of repo ids to serach for the keyword is not limited, we need to get all the issue ids for the shown issue stats
* added "accessibleRepositoryCondition" check on the query to pull the repo ids to search for issues, this is an added protection to ensure we don't search repos the user does not have access to
* added code so that in the issues search, we won't use an in clause of issues ids that goes over 1000
* fixed unit test
* using 950 as the limit for issue search, removed unneeded group by in GetRepoIDsForIssuesOptions, showing search on pulls dashboard page too (not just issues)
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* add API endpoint to create OAuth2 Application.
* move endpoint to /user. Add swagger documentations and proper response type.
* change json tags to snake_case. add CreateOAuth2ApplicationOptions to swagger docs.
* change response status to Created (201)
* add methods to list OAuth2 apps and delete an existing OAuth2 app by ID.
* add APIFormat convert method and file header
* fixed header
* hide secret on oauth2 application list
* add Created time to API response
* add API integration tests for create/list/delete OAuth2 applications.
Co-authored-by: techknowlogick <matti@mdranta.net>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Looking at github/markup#245 it is clear that GH uses https://github.com/jch/html-pipeline to sanitize. This PR relaxes our sanitization to more closely match this.
Fixes#10471
and likely others...
* Show Signer in commit lists and add basic trust
Show the avatar of the signer in the commit list pages as we do not
enforce that the signer is an author or committer. This makes it
clearer who has signed the commit.
Also display commits signed by non-members differently from
members and in particular make it clear when a non-member signer
is different from the committer to help reduce the risk of
spoofing.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* ensure orange text and background is available
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Update gpg_key.go
* Update models/gpg_key.go
* Apply suggestions from code review
* Require team collaborators to have access to UnitTypeCode
* as per @6543
* fix position of sha as per @silverwind
* as per @guillep2k
- Ensure bar does not overflow parent
- Remove unneccessary borders/background
- Fix shaky animation caused by JS animation miscalculation by setting
fixed height on the summary box. Box itself is still shaky during
animation, but better it then the whole page.
Fixes: https://github.com/go-gitea/gitea/issues/10474
* refactor
* optimize
* remove Iretating function
LoadWatchUsers do not load Users into IW object and it is used only in api ... so move this logic
* remove unessesary
* Apply suggestions from code review
Thx
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
* make Tests more robust
* fix rebase
* restart CI
* CI no dont hit sqlites deadlock
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
- Fixes a JWT decoding issue in the OpenID provider
- Updates the GitHub provider to use the authorization header for authentication
- Updates the Twitch provider for Twitch's v5 API changes
- Adds the email and is_private_email fields to the Apple provider's GetUser implementation
- Modifies gothic to export a non-collidable context key for setting the Provider in a context.Context
- Adds new scopes to the Spotify provider
- Adds the IDToken from OpenID providers on the user struct
- Make Apple provider's SecretParams public
- Adds support for sign in with Apple, and drops support for Go versions 1.7 and 1.8
- Fixes the Slack provider's FetchURL logic to use the appropriate scope for the info it needs
Signed-off-by: Oscar LÃfwenhamn <oscar.lofwenhamn@cgi.com>
- unvendor vue and vue-calendar-heatmap
- remove unused moment.js leftover from previous heatmap version
- ensure webpack loads the full version of vue
- fix vue devmode warning related to 'searchLimit' type
I wanted to name the chunk heatmap.js but adblockers don't like that
filename [1].
[1] 3899d5dff3/easyprivacy/easyprivacy_general.txt (L2095)
* Prevent Firefox from using apple-touch-icon
The opaque background does not work well in Firefox which uses the icon
as a "rich icon". Prevent this by not specifying it in HTML. Real Apple
devices will still request the icon on the static path.
Fixes: https://github.com/go-gitea/gitea/issues/10394
Also adjust gitignore so app.ini.sample becomes searchable and fixed a
variable name in app.ini.sample.
* fix gitignore
* Add frontend/backend make targets, fix source release
- Add 'make backend' and 'make frontend' make targets which are used to
build go and js/css/svg files respectively.
- The 'backend' target can be invoked without requiring Node.js to be
present on the system if pre-built frontend assets are present like
in the release source tarballs.
- Fix source releases missing 'dist' folders inside 'node_modules' which
were erronously excluded from tar.
- Store VERSION in file VERSION for the release tarballs and prefer that
file over git-derived version.
* fix release task
* fix typo
* fix another typo
If you attempt to merge to a branch which on a PR there will be a nil pointer error in the pull request checker.
This panic is uncaught and will bring down the gitea server.
This PR adds protection to prevent this.
Move langauge detection to separate module to be more reusable
Add option to disable vendored file exclusion from file search
Allways show all language stats for search
- only `mkdir`the dist dirs when they are absent
- add the dist dirs as prereqs so targets like `make release-sources`
can run standalone
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* Database Preparation
* Apply suggestions from @guillep2k
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Repeat strong password notice on PostgreSQL
* Add prerequisite note
* Use utf8mb4 instead of utf8
* Use utf8mb4 if complete character coverage wanted
* utf8mb4 recommended
* Reword utf8mb4 recommendation
* Set InnoDB global variables may be needed
* Reorder step number
* Whoops, bump year date
* Remove `SET GLOBAL`s and step number reorder
It is assumed that such global variables value are already as default on MySQL 5.7 and later, so those are redundant.
* Syntax edit on MySQL GRANT PRIVILEGEs
* DB engine uniformity intro edit
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
The commit status code has a bug whereby setting the initial status to Pending means you can never have the status of Success - it should be set to Success.
* Truncate long commit message header
* Fix overflow in view commit table
* Use @media less
* Further improvements
* Fix the commit message on small screens
* adjust width of minimal table
* Don't manually replace whitespace during render
For historical reasons Gitea manually alters the urlPrefix and replaces
a whitespace with a +. This Works for URLs, but we're also passing
urlPrefix to git calls and adding the + is breaking the tree path.
Goldmark will automatically convert a white space to the proper %20, so
we should leave the string as is which lets us pass it to git unmodified
and then let Goldmark fix it.
Also fixed separate bug in URLJoin I noticed while testing where it will
silently discard sections of a path that have # in them (possibly
others). We should just escape it first.
Fixes 10156
* Escape elems as well
* Revert "Escape elems as well"
This reverts commit 8bf49596fe.
* restart ci
* remove changes to URLJoin
* restart ci
Co-authored-by: techknowlogick <matti@mdranta.net>
* Add fixture gen tool and fix "access" test
* Close file before exiting
* Add missing repo_unit for repo id: 5
* Fix count on TestAPIOrgRepos
* Generate access fixture from contrib and add test
* Remove old access fixture generation
* Fix lint
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add fixture gen tool and fix "access" test
* Close file before exiting
* Add missing repo_unit for repo id: 5
* Fix count on TestAPIOrgRepos
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* add API branch protection endpoint
* lint
* Change to use team names instead of ids.
* Status codes.
* fix
* Fix
* Add new branch protection options (BlockOnRejectedReviews, DismissStaleApprovals, RequireSignedCommits)
* Do xorm query directly
* fix xorm GetUserNamesByIDs
* Add some tests
* Improved GetTeamNamesByID
* http status created for CreateBranchProtection
* Correct status code in integration test
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Write out TAGS to .make_evidence/tags and compare it to the previous
invocation. If they differ, insert the evidence file into the prereqs
of targets that use TAGS. I made it .PHONY so it always builds.
I did not include the prereq on release tasks, asssuming the will always
do a clean build.
Fixes: https://github.com/go-gitea/gitea/issues/10196
Co-authored-by: techknowlogick <matti@mdranta.net>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* Implementation for calculating language statistics
Impement saving code language statistics to database
Implement rendering langauge stats
Add primary laguage to show in repository list
Implement repository stats indexer queue
Add indexer test
Refactor to use queue module
* Do not timeout for queues
* Only check for merging if the PR has not been merged in the interim
* fixup! Only check for merging if the PR has not been merged in the interim
* Try to fix test failure
* Use PR2 not PR1 in tests as PR1 merges automatically
* return already merged error
* enforce locking
* enforce locking - fix-test
* enforce locking - fix-testx2
* enforce locking - fix-testx3
* move pullrequest checking to after merge
This might improve the chance that the race does not affect us but does not prevent it.
* Remove minor race with getting merge commit id
* fixup
* move check pr after merge
* Remove unnecessary prepareTestEnv - onGiteaRun does this for us
* Add information about when merging occuring
* fix fmt
* More logging
* Attempt to fix mysql
* Try MySQL fix again
* try again
* Try again?!
* Try again?!
* Sigh
* remove the count - perhaps that will help
* next remove the update id
* next remove the update id - make it updated_unix instead
* On failure to merge ensure that the pr is rechecked for conflict errors
* On failure to merge ensure that the pr is rechecked for conflict errors
* Update models/pull.go
* Update models/pull.go
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Apply suggestions from code review
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* allow emoji on popup label
* Make emojify work
* Remove unnecessary class
Co-Authored-By: silverwind <me@silverwind.io>
Co-authored-by: silverwind <me@silverwind.io>
- created lazy-loaded webpack chunk for clipboard.js
- upgraded clipboard.js from 1.5.9 to 2.0.4
- parallelize initialization of all lazy-loaded features
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
- move "vendor" files to js/vendor and less/vendor
- move swagger to js/standalone (meant for standalone pages)
- move gitgraph to features and streamline its loading
- add linting configs to webpack dependencies in make
- set ignored files for eslint/stylelint directly in their configs
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* add check to DeleteUser
* add check to DeleteOrganization
* add Test
* remove redundancy (deleteOrg is only used in DeleteOrganization)
* Update models/org.go
Co-authored-by: zeripath <art27@cantab.net>
* Upgrade levelqueue to version 0.2.0
This adds functionality for Unique Queues
* Add UniqueQueue interface and functions to create them
* Add UniqueQueue implementations
* Move TestPullRequests over to use UniqueQueue
* Reduce code duplication
* Add bytefifos
* Ensure invalid types are logged
* Fix close race in PersistableChannelQueue Shutdown
* Check if go exists before generating the GOPATH
* Move export PATH into Go protected section
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* go function contexting is not what you expect
* Apply suggestions from code review
Co-Authored-By: Lauris BH <lauris@nix.lv>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Use evidence file as dependency instead of dir
* fix eol
* Update .gitignore
Co-Authored-By: silverwind <me@silverwind.io>
* Use FOMANTIC_SOURCES to establish dependencies as per @silverwind
Co-authored-by: silverwind <me@silverwind.io>
* Cache last commit to accelerate the repository directory page visit
* Default use default cache configuration
* add tests for last commit cache
* Simplify last commit cache
* Revert Enabled back
* Change the last commit cache default ttl to 8760h
* Fix test
* Support references ending in , . and ;
* Accept :;, in simple refs; fix 2+ consecutive refs
* Include cross-repository references
* Add ?!, fix spacing problem
this speeds up repeated webpack builds by around 20%. It will use the
default cache directory `node_modules/.cache/babel-loader`.
Also added cache invalidation to workaround https://github.com/babel/babel-loader/issues/690
* fix apple-touch-icon, regenerate images
Fixed semi-transparent pixels of apple-touch-icon.png.
I had to manually exclude public/img/loading.png from the commit because
it's an APNG and one of the tools destroys the animation.
* exclude loading.png
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add doctor check of app.ini paths
* Make /custom dir not mandatory
* Fix message and improve interface
* Update cmd/doctor.go
Co-Authored-By: John Olheiser <42128690+jolheiser@users.noreply.github.com>
* Apaise lint
* Isn't the linter a sweet? (1)
* Isn't the linter a sweet? (2)
* Isn't the linter a sweet?? (3)
* Restart CI
Co-authored-by: John Olheiser <42128690+jolheiser@users.noreply.github.com>
Co-authored-by: zeripath <art27@cantab.net>
* Update documentation for the go module era
use go env instead of $GOPATH
Update instructions to just use git clone
Slight update to readme
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fixup
* Apply suggestions from code review
Co-Authored-By: Antoine GIRARD <sapk@users.noreply.github.com>
Co-Authored-By: Bagas Sanjaya <bagasdotme@gmail.com>
* Apply suggestions from code review
* Fix GOPATH settings
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: Bagas Sanjaya <bagasdotme@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Make WorkerPools and Queues flushable
Adds Flush methods to Queues and the WorkerPool
Further abstracts the WorkerPool
Adds a final step to Flush the queues in the defer from PrintCurrentTest
Fixes an issue with Settings inheritance in queues
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Change to for loop
* Add IsEmpty and begin just making the queues composed WorkerPools
* subsume workerpool into the queues and create a flushable interface
* Add manager command
* Move flushall to queue.Manager and add to testlogger
* As per @guillep2k
* as per @guillep2k
* Just make queues all implement flushable and clean up the wrapped queue flushes
* cope with no timeout
Co-authored-by: Lauris BH <lauris@nix.lv>
because the CSS was lazy-loaded the rules in arc-green did not win.
included the css file in the main bundle to fix. the black dots can not
be fixed via CSS because they are drawn in a `<canvas>` element
unfortunately.
- introduced window.config to help with js-based lazy-loading
- adjusted webpack chunk naming to avoid 'vendors~name.js' that webpack
defaults to for vendor chunks.
- added theme class to html and prefixed all selectors. this is
neccesary so that the theme styles win over the lazy-loaded ones.
Co-authored-by: zeripath <art27@cantab.net>
* Always limit results by what is accessible to the user
* Change signature of AccessibleRepoIDsQuery
* Ensure that user with ID <= 0 is handled
* Update models/repo_list.go
* Repo name added to automatically generated commit message when merging pull request
* As per @lunny
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: zeripath <art27@cantab.net>
* Some refactor on git diff and ignore getting commit information failed on migrating pull request review comments
* fix test
* fix lint
* Change error log to warn
- added new 'make webpack' target
- deprecated 'make js' and 'make css'
- extend webpack config to load the less files
- updated docs
I had to rename the source file of `arc-green.less` to avoid generating
a useless JS entrypoint via webpack-fix-style-only-entries which would
not work with different source/destination filenames. I hear that there
should be cleaner solutions possible once we upgrade to Webpack 5.
Co-authored-by: zeripath <art27@cantab.net>
* Only generate bindata if necessary
* Only generate bindata if they are not up-to-date
* generate a hash of the fileinfo and use that to keep up-to-date
* Newer test is redundant
* handle missing bindata and clean
* Only update hash after successful write
* switch to sha1 hash
* Apply suggestions from code review
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* add explicit dimensions to navbar avatar
this prevents a temporary layout change when navigating between
pages with cache disabled.
* also add dimensions on frontpage
Co-authored-by: Lauris BH <lauris@nix.lv>
the `fomantic` target for some reason does sometimes not update the
timestamp on the directory, leading to useless rebuild. Manually update
the timestamp at the end of the build to avoid this and also added the
same to js/css targets.
* fix commit view JS features, reimplement folding
File content folding was not working so I reimplemented it in a saner
way. Then I noticed the issue was actually because of missing JS
libraries (seen on the console of every commit with error
'SimpleMDE is not defined').
Fixed the libraries. I think the reimplementation is worth to keep.
* add .closest polyfill
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
loadCSS was used as a polyfill for rel=preload but it seems we only used
it on a single CSS file which did not help much. Changed the icon CSS to
a blocking load and preload the woff2 variants which does work in modern
browsers (Firefox currently needs the network.preload about:config
setting but should gain proper support soon).
Co-authored-by: zeripath <art27@cantab.net>
* combine make calls on drone
combine most make calls on drone into one command. this should give a
speedup of about 5-15 seconds per make invocation because make only
needs to resolve file globs once.
* combine timeout calls as well
* make node_modules a order-only prerequisite
Package installations and our fomantic step results in changes inside
node_modules which lead to make triggering that target unnecessarily.
Moved all node_modules prerequisites to order-only which will make skip
the timestamp check on in and eliminate useless npm calls.
Changes in package-lock.json will still result in reinstallation so
node_modules should stay consistent.
* revert change to clean-all
This changes the CSS output of webpack to output to the public/css
directory instead of inling CSS in JS. This enables CSS minification and
autoprefixer based on browserslist which would otherwise not be
possible.
The result of this change is two new output files currently:
- public/css/swagger.css
- public/css/gitgraph.css
Co-authored-by: techknowlogick <matti@mdranta.net>
* fix pull view when head repository or head branch missed and close related pull requests when delete branch
* fix pull view broken when head repository deleted
* close pull requests when head repositories deleted
* Add tests for broken pull request head repository or branch
* fix typo
* ignore special error when close pull request
Co-authored-by: Lauris BH <lauris@nix.lv>
* fix typo
* Migrate reviews when migrating repository from github
* fix lint
* Added test and migration when external user login
* fix test
* fix commented state
* Some improvements
* fix bug when get pull request and ref original author on code comments
* Fix migrated line; Added comment for review
* Don't load all pull requests attributes
* Fix typo
* wrong change copy head
* fix tests
* fix reactions
* Fix test
* fix fmt
* fix review comment reactions
* Fix wrong hint when status checking is running on pull request view
* fix lint
* fix test
* fix test
* fix wrong tmpl
* fix import
* rename function name
Currently, this needs to be its own chunk because fomantic depends
on jQuery being present. The next step is to move fomantic to webpack
too after which we can combine the index,fomantic and jquery files into
one.
jquery-migrate is still neccessary because our ancient version of Dropzone
seems to break without it. I imagine it can be removed after a Dropzone
upgrade.
* fixed link to issue in issue comments after adding/removing a dependency, before links assumed the issue was in the same repository. also changed the format of the displayed issue since the issue will not necessarily be in the same repo
* based on pr comments, changed to use HTMLURL instead of piecing together the issue url, and added an if statement around the issue link display as a nil protection
* only showing repo name in dependency comment if the issue is from another repo
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* Use npm to manage fomantic
* Only build needed semantic components
* Fix make
* Don't import fonts from google sites since we have loaded
* [misc] devendor fomantic-ui and rebuild upon src or config changes only
Signed-off-by: Jakob Ackermann <das7pad@outlook.com>
* Change sort alphabetically of semantic components
* Fix trailing slash
* fix makefile
* Remove dependency to gulp from package.json
* Fix something
* Simplife the makefile
* add missed fomantic compnent
Co-authored-by: Jakob Ackermann <das7pad@outlook.com>
* Add support for database schema
* Require setting search_path for the db user
* Add schema setting to admin/config.tmpl
* Use a schema different from default for psql tests
* Update postgres scripts to use custom schema
* Update to xorm/core 0.7.3 and xorm/xorm c37aff9b3a
* Fix migration test
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Fix wrong permissions check when issues/prs shared operations
* move redirect to the last of the function
* fix swagger
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Make CertFile and KeyFile relative to CustomPath
The current code will absolute CertFile and KeyFile against the current working directory. This is quite unexpected for users. This code makes relative paths absolute against the CustomPath.
Fix#4196
* Improve error reporting when reading certificates
* Apply suggestions from code review
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
* Add possibility to global disable repo units.
* Add Default Repo Unit app.ini setting.
* Hide units
* Hide disabled repo units
* Minor fixes
* Indicate disabled units in team settings.
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
* Admin shall be able to bypass merge checks.
* Repository admin should not bypass if merge whitelist is set.
* Add code comment about checks that PR are ready
* notAllOverrideableChecksOk->notAllOverridableChecksOk
* Fix merge, require signed currently not overridable.
* fix
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* ci: configure remaining github limmit
* prepend with github since package is common to all migrations
* add RefreshRate
* Update github.go
* add missing space
* go fmt
* Read env variable GITHUB_READ_TOKEN for token
* Update .drone.yml
Now includes Firefox ESR, Opera and a few more browser with usages
between 0.5% and 1%. defaults resolves to > 0.5%, last 2 versions, Firefox ESR, not dead.
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add require signed commit for protected branch
* Fix fmt
* Make editor show if they will be signed
* bugfix
* Add basic merge check and better information for CRUD
* linting comment
* Add descriptors to merge signing
* Slight refactor
* Slight improvement to appearances
* Handle Merge API
* manage CRUD API
* Move error to error.go
* Remove fix to delete.go
* prep for merge
* need to tolerate \r\n in message
* check protected branch before trying to load it
* Apply suggestions from code review
Co-Authored-By: guillep2k <18600385+guillep2k@users.noreply.github.com>
* fix commit-reader
Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>
Created a second webpack output file for swagger-ui which is loaded on
the /api/swagger route. One notable difference is the absence of the
swagger favicon that was previously used which is now the gitea icon. I
see no easy way to restore that favicon, so I decided to not keep it.
* introduce GET /notifications/new
* add TEST
* use Sprintf instead of path.Join
* Error more verbose
* return number of notifications if unreaded exist
* 200 http status for available notifications
* Add privacy policy page and link
* Add TOS page and link
* Add update date
* [Docs] Add customizing PP and TOS
* Separate h2 user-generated content with its paragraph
* Reimplement Privacy Policy
The document is inspired from GitHub.
* Refactor to contrib
* [Docs] Mention how to add legal pages
* Reimplement Terms of Service
Adapted from GitHub
* Update revision date
* Rename to mark as sample file
* Apply suggestion from @sapk
Co-Authored-By: Antoine GIRARD <sapk@users.noreply.github.com>
* Apply suggestion from @sapk
Use absolute link instead
Co-Authored-By: Antoine GIRARD <sapk@users.noreply.github.com>
* Apply suggestion from @zeripath
Change `Last Updated` element to `<h4>`
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Close this `<li>` element instance
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Intentionally grammar fix
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Information grammar
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Cannot guarantee absolute security...
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Use `<h4>` element for last updated date
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Remove trailing `</p>` at the end of API clause
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Migrate privacy email domain to Your Gitea Instance
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestions from @zeripath
Remove `<p>` container for `<ol>` definitions
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestions from @zeripath
Remove `<p>` container that contain `<ol>` user-generated content
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestions from @zeripath
Remove `<p>` container for private repositories `<ol>` listing
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestions from @zeripath
Migrate remaining email domains to Your Gitea Instance
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Offer support
Co-Authored-By: zeripath <art27@cantab.net>
* Apply suggestion from @zeripath
Change "Your Gitea Instance" references to match your situation and Gitea project disclaimer
Co-Authored-By: zeripath <art27@cantab.net>
* Reword transmission data to reflect hosting on third-party provider
* Reword Analytics clause to reflects that not all Gitea instances deploy analytics OOTB
* Remove `<p>` container from account terms
* Migrate support email on tos to your-gitea-instance
* Reword Tracking and Analytics clause for OOTB case
* [Docs] Append privacy.html to cp destination
* Apply suggestion from @6543
Create or append to footer template
Co-Authored-By: 6543 <6543@obermui.de>
* Apply suggestion from myself
@6543 suggest replacing this `cp` line (which assumed that Gitea sources are available) with `wget` to GitHub raw link. At the time of writing this, this returned 404, but when this PR has been merged, this should get the actual page.
* Apply suggestions from @6543
1. Add gpg key to profile information
2. Add Git repos to list of User Personal Information
3. Comment out responsibility for sensitive information
Co-Authored-By: 6543 <6543@obermui.de>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
* Fix missing updated time on migrated issues and comments
* Fix testing and missing updated on migrating pullrequest
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
* Restricted users (#4334): initial implementation
* Add User.IsRestricted & UI to edit it
* Pass user object instead of user id to places where IsRestricted flag matters
* Restricted users: maintain access rows for all referenced repos (incl public)
* Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses
* Add basic repo access tests for restricted users
Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* Mention restricted users in the faq
Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* Revert unnecessary change `.isUserPartOfOrg` -> `.IsUserPartOfOrg`
Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* Remove unnecessary `org.IsOrganization()` call
Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* Revert to an `int64` keyed `accessMap`
* Add type `userAccess`
* Add convenience func updateUserAccess()
* Turn accessMap into a `map[int64]userAccess`
Signed-off-by: Manush Dodunekov <manush@stendahls.se>
* or even better: `map[int64]*userAccess`
* updateUserAccess(): use tighter syntax as suggested by lafriks
* even tighter
* Avoid extra loop
* Don't disclose limited orgs to unauthenticated users
* Don't assume block only applies to orgs
* Use an array of `VisibleType` for filtering
* fix yet another thinko
* Ok - no need for u
* Revert "Ok - no need for u"
This reverts commit 5c3e886aab.
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
* ci: try re-ordering for optimizing time
* ci: try re-ordering for optimizing time
* ci: try re-ordering for optimizing time
* ci: try re-ordering for optimizing time
* ci: try re-ordering for optimizing time
* ci: try re-ordering for optimizing time
* ci: try offloading mysql8 to arm64
* Revert "ci: try offloading mysql8 to arm64"
This reverts commit c60de5db1c.
* ci: try offloading pgsql to arm64
* ci: activate ldap on arm64
* ci: test mysql8 in place pgsql arm64
* chore: clean un-needed move
* typo
* ci: revert runnning mysql on arm64
* ci: run compliance on arm
* chore: limit change
* chore: readd maybe need for release fetch-tags
* ci: remove docker-linux-amd64-dry-run
* ci: remove docker-linux-amd64-dry-run
* Revert "ci: remove docker-linux-amd64-dry-run"
This reverts commit 0715f65b11.
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Some users (like me) have this option disabled in their global npm
config which can lead to package-lock.json not being updated. This
explicitely enables the option for this repo, so that the file is
always updated when adding/removing dependencies.
Co-authored-by: techknowlogick <matti@mdranta.net>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
webpack polyfills did not work because useBuiltIns: 'entry' expects a
explicit core-js import. Changed it to 'usage' which does not require
these explicit imports and polyfills based on browserslist.
As a result, the built index.js now went from 128kB to 192kB.
Ref: https://babeljs.io/docs/en/babel-preset-env#usebuiltins
Co-authored-by: zeripath <art27@cantab.net>
* introduce `GET /orgs`
* add TEST
* show also other VisibleType's
* update description
* refactor a lot
* SearchUserOptions by default return only public
* Delay printing hook statuses until after 1 second
* Move to a 5s delay, wrapped writer structure and add config
* Update cmd/hook.go
* Apply suggestions from code review
* Update cmd/hook.go
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Fomantic expects all tabs to have a target element with content as
defined by the data-tab attribute. All our usage of the tab module seems
to use <a> element tabs that link to new pages so these content elements
are never present and fomantic complains about that in the console with
an "Activated tab cannot be found" error. This silences that error.
* add doctor
* Add a new command doctor to check if some wrong configurations on gitea instance
* fix import
* use regex match authorized_keys on doctor
* Add documentation
* Move push commits from models to modules/repository
* fix test
* fix test
* fix test
* fix test
* fix test
Co-authored-by: zeripath <art27@cantab.net>
* deprecate /api/v1/org/{org}/repos in favour of /api/v1/orgs/{org}/repos + cleanup api repository routes a bit
* remove redundant code
* use upstream function for api cal
* make generate-swagger
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
* API: orgEditTeam make Fields optional
* add TestCase
* Update integrations/api_team_test.go
* suggestions from lafriks
use len() to check if string is empty
Co-Authored-By: Lauris BH <lauris@nix.lv>
* change ...
* use Where not ID to get mssql
* add return and code format
* fix test
* fix test ... null pointer exept
* update specific colums
* only specific colums too
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Fix#5997.
If a push causes the patch/diff of a PR towards target branch to change, all existing reviews for the PR will be set and shown as stale.
New branch protection option to dismiss stale approvals are added.
To show that a review is not based on the latest PR changes, an hourglass is shown
* Rename h3 title
* Add intro
Should work on Ubuntu Xenial, but should work on any Linux distros.
* Indirect edit files
Instead of providing `sudo vim`, invite to edit files.
* enable now instead of enable and start
* Re-add systemctl enable && systemctl start
* Revert service enablement back to status quo
* Add enable now counterpart for systemd > v220
* Apply suggestions from @sapk
Strip `vim` from editor usage
Co-Authored-By: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
cd$(DIST);for file in `find /build -type f -name "*"`;do cp $${file} ./release/;done;
.PHONY:release-check
release-check:
release-check:|$(DIST_DIRS)
cd$(DIST)/release/;for file in `find . -type f -name "*"`;doecho"checksumming $${file}"&&$(SHASUM)`echo$${file}| sed 's/^..//'` > $${file}.sha256;done;
.PHONY:release-compress
release-compress:
release-compress:|$(DIST_DIRS)
@hash gxz > /dev/null 2>&1;if[$$? -ne 0];then\
$(GO) get -u github.com/ulikunitz/xz/cmd/gxz;\
GO111MODULE=off $(GO) get -u github.com/ulikunitz/xz/cmd/gxz;\
fi
cd$(DIST)/release/;for file in `find . -type f -name "*"`;doecho"compressing $${file}"&& gxz -k -9 $${file};done;
.PHONY:release-sources
release-sources:|$(DIST_DIRS)node_modules
echo$(VERSION) > $(STORED_VERSION_FILE)
tar --exclude=./$(DIST) --exclude=./.git --exclude=./$(MAKE_EVIDENCE_DIR) --exclude=./node_modules/.cache -czf $(DIST)/release/gitea-src-$(VERSION).tar.gz .
<h1><imgsrc="https://raw.githubusercontent.com/go-gitea/gitea/master/public/img/gitea-192.png"alt="logo"width="30"height="30"> Gitea - Git with a cup of tea</h1>
[](https://discord.gg/NsatcWJ)
[](https://discord.gg/Gitea)
[](https://microbadger.com/images/gitea/gitea "Get your own image badge on microbadger.com")
<h1><imgsrc="https://raw.githubusercontent.com/go-gitea/gitea/master/public/img/gitea-192.png"alt="logo"width="30"height="30"> Gitea - Git with a cup of tea</h1>
[](https://discord.gg/NsatcWJ)
[](https://discord.gg/Gitea)
[](https://microbadger.com/images/gitea/gitea "Get your own image badge on microbadger.com")
Usage:"Minimal cell width including any padding for the formatted table",
Value:0,
},
cli.IntFlag{
Name:"tab-width",
Usage:"width of tab characters in formatted table (equivalent number of spaces)",
Value:8,
},
cli.IntFlag{
Name:"padding",
Usage:"padding added to a cell before computing its width",
Value:1,
},
cli.StringFlag{
Name:"pad-char",
Usage:`ASCII char used for padding if padchar == '\\t', the Writer will assume that the width of a '\\t' in the formatted output is tabwidth, and cells are left-aligned independent of align_left (for correct-looking results, tabwidth must correspond to the tab width in the viewer displaying the result)`,
Value:"\t",
},
cli.BoolFlag{
Name:"vertical-bars",
Usage:"Set to true to print vertical bars between columns",
return[]string{"authorized_keys is out of date, attempting regeneration"},models.RewriteAllPublicKeys()
}
returnnil,fmt.Errorf(`authorized_keys is out of date and should be regenerated with "gitea admin regenerate keys" or "gitea doctor --run authorized_keys --fix"`)
return[]string{fmt.Sprintf("WARN: Got Error %v during ensure up to date",err),"Attempting to migrate to the latest DB version to fix this."},models.NewEngine(context.Background(),migrations.Migrate)
results=append(results,fmt.Sprintf("WARN: Unable to get merge base for PR ID %d, #%d onto %s in %s/%s",pr.ID,pr.Index,pr.BaseBranch,pr.BaseRepo.OwnerName,pr.BaseRepo.Name))
log.Error("Unable to get merge base for PR ID %d, Index %d in %s/%s. Error: %v & %v",pr.ID,pr.Index,pr.BaseRepo.OwnerName,pr.BaseRepo.Name,err,err2)
results=append(results,fmt.Sprintf("WARN: Unable to get parents for merged PR ID %d, #%d onto %s in %s/%s",pr.ID,pr.Index,pr.BaseBranch,pr.BaseRepo.OwnerName,pr.BaseRepo.Name))
log.Error("Unable to get parents for merged PR ID %d, Index %d in %s/%s. Error: %v",pr.ID,pr.Index,pr.BaseRepo.OwnerName,pr.BaseRepo.Name,err)
results=append(results,fmt.Sprintf("WARN: Unable to get merge base for merged PR ID %d, #%d onto %s in %s/%s",pr.ID,pr.Index,pr.BaseBranch,pr.BaseRepo.OwnerName,pr.BaseRepo.Name))
log.Error("Unable to get merge base for merged PR ID %d, Index %d in %s/%s. Error: %v",pr.ID,pr.Index,pr.BaseRepo.OwnerName,pr.BaseRepo.Name,err)
returnresults,nil
}
}
pr.MergeBase=strings.TrimSpace(pr.MergeBase)
ifpr.MergeBase!=oldMergeBase{
ifctx.Bool("fix"){
iferr:=pr.UpdateCols("merge_base");err!=nil{
returnresults,err
}
}else{
results=append(results,fmt.Sprintf("#%d onto %s in %s/%s: MergeBase should be %s but is %s",pr.Index,pr.BaseBranch,pr.BaseRepo.OwnerName,pr.BaseRepo.Name,oldMergeBase,pr.MergeBase))
}
numPRsUpdated++
}
returnresults,nil
})
})
ifctx.Bool("fix"){
results=append(results,fmt.Sprintf("%d PR mergebases updated of %d PRs total in %d repos",numPRsUpdated,numPRs,numRepos))
}else{
ifnumPRsUpdated>0&&err==nil{
returnresults,fmt.Errorf("%d PRs with incorrect mergebases of %d PRs total in %d repos",numPRsUpdated,numPRs,numRepos)
}
results=append(results,fmt.Sprintf("%d PRs with incorrect mergebases of %d PRs total in %d repos",numPRsUpdated,numPRs,numRepos))
<p>We collect following personal data (collectively called User Personal Information):</p>
<ol>
<li>Registration information (username, email, password, etc.)</li>
<li>Profile information for your Account (such as your full name, biography, website, gpg key, and location.)</li>
<li>Usage information (pages you view, your IP address, referring site, session information, and request date and time.)</li>
<li>Device information (its IP address, client application information, language preference, operating system and application version, device type, ID, model and manufacturer.)</li>
<li>Git data that you upload to a repository</li>
<li>Cookies and Similar Technologies</li>
</ol>
<p>We may also collect User Personal Information from third-parties (vendors, partners, or affiliates). We don't purchase them from third-party data brokers, though.</p>
<p>However, we don't intentionally collect sensitive information (such as racial or ethnic origin, political affiliations, religious/philosophical beliefs, biometric data, etc.)</p>
<!--If you choose to store any of such data on our servers, you are responsible for complying with any regulations regarding them.-->
<h2>How We Share Information We Collect?</h2>
<p>We may share your User Personal Information with third-parties under following circumstances:</p>
<h3>With your Consent</h3>
<p>We share your User Personal Information, if you consent, after letting you know what information will be shared, with whom, and why. For example, if you allow third party applications to access your Account using <a href="https://docs.gitea.io/en-us/oauth2-provider/">OAuth2 providers</a>, we share all information associated with your Account, including private repos and organizations. You may also direct us through your action on Your Gitea Instance to share your User Personal Information, such as when joining an Organization.</p>
<h3>With Service Providers</h3>
<p>We share User Personal Information with a limited number of service providers who process it on our behalf to provide or improve our Service, and who have agreed to privacy restrictions similar to the ones in our Privacy Statement by signing data protection agreements or making similar commitments. Our service providers perform payment processing, customer support ticketing, network data transmission, security, and other similar services. While Your Gitea Instance processes all User Personal Information in the (country/state where Gitea is deployed), our service providers may process data outside of (country/state where Gitea is deployed), the United States or the European Union.</p>
<h3>For Security Purposes</h3>
<p>If you are a member of an Organization, Your Gitea Instance may share your username, Usage Information, and Device Information associated with that Organization with an owner and/or administrator of the Organization who has agreed to the Corporate Terms of Service or applicable customer agreements, to the extent that such information is provided only to investigate or respond to a security incident that affects or compromises the security of that particular Organization.</p>
<h3>For Legal Disclosure</h3>
<p>Your Gitea Instance strives for transparency in complying with legal process and legal obligations. Unless prevented from doing so by law or court order, or in rare, exigent circumstances, we make a reasonable effort to notify users of any legally compelled or required disclosure of their information. Your Gitea Instance may disclose User Personal Information or other information we collect about you to law enforcement if required in response to a valid subpoena, court order, search warrant, a similar government order, or when we believe in good faith that disclosure is necessary to comply with our legal obligations, to protect our property or rights, or those of third parties or the public at large.</p>
<h3>Change in Control or Sale</h3>
<p>We may share User Personal Information if we are involved in a merger, sale, or acquisition of corporate entities or business units. If any such change of ownership happens, we will ensure that it is under terms that preserve the confidentiality of User Personal Information, and we will notify you on our Website or by email before any transfer of your User Personal Information. The organization receiving any User Personal Information will have to honor any promises we made in our Privacy Statement or Terms of Service.</p>
<p>We share certain aggregated, non-personally identifying information with others about how our users, collectively, use Your Gitea Instance, or how our users respond to our other offerings, such as our conferences or events. For example, we may compile statistics on the open source activity across Your Gitea Instance.</p>
<p>We <b>don't</b> sell your User Personal Information for monetary or other consideration. </p>
<h2>How We Use Your Information?</h2>
<p>We may use your information for following purposes:</p>
<ol>
<li>We use your Registration Information to create your account, and to provide you the Service.</li>
<li>We use your User Personal Information, specifically your username, to identify you on Your Gitea Instance.</li>
<li>We use your Profile Information to fill out your Account profile and to share that profile with other users if you ask us to.</li>
<li>We use your email address to communicate with you, if you've said that's okay, and only for the reasons you’ve said that’s okay.</li>
<li>We use User Personal Information and other data to make recommendations for you, such as to suggest projects you may want to follow or contribute to. We learn from your public behavior on Your Gitea Instance—such as the projects you star—to determine your coding interests, and we recommend similar projects. These recommendations are automated decisions, but they have no legal impact on your rights.</li>
<li>We use Usage Information and Device Information to better understand how our Users use Your Gitea Instance and to improve our Website and Service.</li>
<li>We may use your User Personal Information if it is necessary for security purposes or to investigate possible fraud or attempts to harm Your Gitea Instance or our Users.</li>
<li>We may use your User Personal Information to comply with our legal obligations, protect our intellectual property, and enforce our Terms of Service.</li>
<li>We limit our use of your User Personal Information to the purposes listed in this Privacy Statement. If we need to use your User Personal Information for other purposes, we will ask your permission first. You can always see what information we have, how we're using it, and what permissions you have given us in your user profile.</li>
</ol>
<h2>How Your Gitea Instance Secures Your Information?</h2>
<p>Your Gitea Instance takes all measures reasonably necessary to protect User Personal Information from unauthorized access, alteration, or destruction; maintain data accuracy; and help ensure the appropriate use of User Personal Information.</p>
<p>To the extent above, we enforce a written security information program, which:</p>
<ul>
<li>aligns with industry recognized frameworks;</li>
<li>includes security safeguards reasonably designed to protect the confidentiality, integrity, availability, and resilience of our Users' data;</li>
<li>is appropriate to the nature, size, and complexity of Your Gitea Instance’s business operations;</li>
<li>includes incident response and data breach notification processes; and</li>
<li>complies with applicable information security-related laws and regulations in the geographic regions where Your Gitea Instance does business.</li>
</ul>
<p>In the event of a data breach that affects your User Personal Information, we will act promptly to mitigate the impact of a breach and notify any affected Users without undue delay.</p>
<p>Transmission of data on Your Gitea Instance is encrypted using SSH, HTTPS (TLS), and git repository content is encrypted at rest. We host Your Gitea Instance at our hosting partner, which they provide data centers with high level of physical and network security.</p>
<p><b>Disclaimer:</b> No method of transmission, or method of electronic storage, is 100% secure, therefore, we cannot guarantee absolute security.</p>
<h2>Cookies and Tracking Usage</h2>
<h3>Cookies</h3>
<p>We uses cookies to make interactions with our service easy and meaningful. Cookies are small text files that websites often store on computer hard drives or mobile devices of visitors. We use cookies (and similar technologies, like HTML5 localStorage) to keep you logged in, remember your preferences, and provide information for future development of Your Gitea Instance. For security purposes, we use cookies to identify a device. By using our Website, you agree that we can place these types of cookies on your computer or device. If you disable your browser or device’s ability to accept these cookies, you will not be able to log in or use our services.</p>
<h3>Tracking and Analytics</h3>
<p>Out of the box, Gitea doesn't use third-party analytics. In case when we opt in to their usage, we do that to help us evaluate our Users' use of Your Gitea Instance, compile statistical reports on activity, and improve our content and Website performance. We only use these third-party analytics providers on certain areas of our Website, and all of them have signed data protection agreements with us that limit the type of User Personal Information they can collect and the purpose for which they can process the information. In addition, we may also deploy internal analytics software to provide similar functionality.</p>
<p>Some browsers have incorporated "Do Not Track" (DNT) features that can send a signal to the websites you visit indicating you do not wish to be tracked. Your Gitea Instance responds to browser DNT signals and follows the <a href="https://www.w3.org/TR/tracking-dnt/">W3C standard for responding to DNT signals</a>. If you have not enabled DNT on a browser that supports it, cookies on some parts of our Website will track your online browsing activity on other online services over time, though we do not permit third parties other than our analytics and service providers to track Your Gitea Instance Users' activity over time on Your Gitea Instance.</p>
<h2>Repository Contents</h2>
<p>Our employees do not access private repositories unless required to for security purposes, for support, to maintain integrity of the Service, or to comply with our legal obligations. While we don't generally search for content in your repositories, we may scan our servers and your content to detect tokens or security signatures, known malwares, or child exploitation imagery.</p>
<p>If your repository is public, anyone may view its contents. If you include private, confidential or Sensitive Personal Information, such as email addresses or passwords, in your public repository, that information may be indexed by search engines or used by third parties.</p>
<h2>Public Information</h2>
<p>Many of our services and feature are public-facing. If your content is public-facing, third parties may access and use it in compliance with our Terms of Service, such as by viewing your profile or repositories or pulling data via our API. We do not sell that content; it is yours. However, we do allow third parties, such as research organizations or archives, to compile public-facing Your Gitea Instance information. Other third parties, such as data brokers, have been known to scrape Your Gitea Instance and compile data as well.</p>
<p>Your User Personal Information associated with your content could be gathered by third parties in these compilations of Your Gitea Instance data. If you do not want your User Personal Information to appear in third parties’ compilations of Your Gitea Instance data, please do not make your User Personal Information publicly available and be sure to configure your email address to be private in your user profile and in your git commit settings.</p>
<p>If you would like to compile Your Gitea Instance data, you must comply with our Terms of Service regarding scraping and privacy, and you may only use any public-facing User Personal Information you gather for the purpose for which our user authorized it. For example, where a Your Gitea Instance user has made an email address public-facing for the purpose of identification and attribution, do not use that email address for commercial advertising. We expect you to reasonably secure any User Personal Information you have gathered from Your Gitea Instance, and to respond promptly to complaints, removal requests, and "do not contact" requests from Your Gitea Instance or Your Gitea Instance users.</p>
<p>In similar fashion, projects on Your Gitea Instance may include publicly available User Personal Information collected as part of the collaborative events.</p>
<h2>Organizations</h2>
<p>If you collaborate on or become a member of an Organization, then its Account owners may receive your User Personal Information. When you accept an invitation to an Organization, you will be notified of the types of information owners may be able to see. If you accept an invitation to an Organization with a verified domain, then the owners of that Organization will be able to see your full email address(es) within that Organization's verified domain(s).</p>
<p>Please note, Your Gitea Instance may share your username, Usage Information, and Device Information with the owner of the Organization you are a member of, to the extent that your User Personal Information is provided only to investigate or respond to a security incident that affects or compromises the security of that particular Organization.</p>
<p>If you collaborate with or become a member of an Account that has agreed to a Data Protection Addendum (DPA) to this Privacy Policy, then that DPA governs in the event of conflicts between this Privacy Policy and DPA with respect to your activity in the Account.</p>
<p>Please contact the Account owners for more information about how they might process your User Personal Information in their Organization and the ways for you to access, update, alter, or delete the User Personal Information stored in the Account.</p>
<h2>How You Can Access and Control the Information We Collect?</h2>
<p>If you're already a Your Gitea Instance user, you may access, update, alter, or delete your basic user information by editing your user profile. You can control the information we collect about you by limiting what information is in your profile, or by keeping your information current.</p>
<p>If Your Gitea Instance processes information about you, such as information receives from third parties, and you do not have an account, then you may, subject to applicable law, access, update, alter, delete, or object to the processing of your personal information by contacting our support.</p>
<h3>Data Portability</h3>
<p>As a Your Gitea Instance User, you can always take your data with you. You can clone your repositories to your computer, or you can <a href="https://docs.gitea.io/en-us/migrations-interfaces/">perform migrations using the provided interfaces</a>, for example.</p>
<h3>Data Retention and Deletion of Data</h3>
<p>In general, Your Gitea Instance retains User Personal Information for as long as your account is active, or as needed to provide you service.</p>
<p>If you would like to cancel your account or delete your User Personal Information, you may do so in your user profile. We retain and use your information as necessary to comply with our legal obligations, resolve disputes, and enforce our agreements, but barring legal requirements, we will delete your full profile (within reason) within 90 days of your request. Feel free to contact our support to request erasure of the data we process on the bassis of consent within 30 days.</p>
<p>After an account has been deleted, certain data, such as contributions to other Users' repositories and comments in others' issues, will remain. However, we will delete or de-identify your User Personal Information, including your username and email address, from the author field of issues, pull requests, and comments by associating them with a ghost user.</p>
<p>That said, the email address you have supplied via your Git commit settings will always be associated with your commits in the Git system. If you choose to make your email address private, you should also update your Git commit settings. We are unable to change or delete data in the Git commit history — the Git software is designed to maintain a record — but we do enable you to control what information you put in that record.</p>
<h2>Our Global Privacy Practices</h2>
<p>We store and process the information that we collect in the (country/state where Gitea is deployed) in accordance with this Privacy Statement though our service providers may store and process data outside the (country/state where Gitea is deployed). However, we understand that we have Users from different countries and regions with different privacy expectations, and we try to meet those needs even when the (country/state where Gitea is deployed) does not have the same privacy framework as other countries.</p>
<p>We provide a high standard of privacy protection—as described in this Privacy Statement—to all our users around the world, regardless of their country of origin or location, and we are proud of the levels of notice, choice, accountability, security, data integrity, access, and recourse we provide. We work hard to comply with the applicable data privacy laws wherever we do business, working with our Data Protection Officer as part of a cross-functional team that oversees our privacy compliance efforts. Additionally, if our vendors or affiliates have access to User Personal Information, they must sign agreements that require them to comply with our privacy policies and with applicable data privacy laws.</p>
<p>In particular:</p>
<ul>
<li>Your Gitea Instance provides clear methods of unambiguous, informed, specific, and freely given consent at the time of data collection, when we collect your User Personal Information using consent as a basis.</li>
<li>We collect only the minimum amount of User Personal Information necessary for our purposes, unless you choose to provide more. We encourage you to only give us the amount of data you are comfortable sharing.</li>
<li>We offer you simple methods of accessing, altering, or deleting the User Personal Information we have collected, where legally permitted.</li>
<li>We provide our Users notice, choice, accountability, security, and access regarding their User Personal Information, and we limit the purpose for processing it. We also provide our Users a method of recourse and enforcement. These are the Privacy Shield Principles, but they are also just good practices.</li>
</ul>
<h2>How We Communicate with You?</h2>
<p>We use your email address to communicate with you, if you've said that's okay, and only for the reasons you’ve said that’s okay. For example, if you contact our support with a request, we respond to you via email. You have a lot of control over how your email address is used and shared on and through Your Gitea instance. You may manage your communication preferences in your user profile.</p>
<p>By design, the Git version control system associates many actions with a User's email address, such as commit messages. We are not able to change many aspects of the Git system. If you would like your email address to remain private, even when you’re commenting on public repositories, you can create a private email address in your user profile. You should also update your local Git configuration to use your private email address. This will not change how we contact you, but it will affect how others see you.</p>
<p>Depending on your email settings, Your Gitea instance may occasionally send notification emails about changes in a repository you’re watching, new features, requests for feedback, important policy changes, or to offer customer support. We also send marketing emails, based on your choices and in accordance with applicable laws and regulations. There's an “unsubscribe” link located at the bottom of each of the marketing emails we send you. Note that you can opt out of any communications with us, except the important ones (like from our support and system emails).</p>
<p>Our emails may contain a pixel tag, which is a small, clear image that can tell us whether or not you have opened an email and what your IP address is. We use this pixel tag to make our email more effective for you and to make sure we’re not sending you unwanted email.</p>
<h2>Changes to this Privacy Policy</h2>
<p>Although most changes are likely to be minor, Your Gitea Instance may change our Privacy Statement from time to time. We will provide notification to Users of material changes to this Privacy Statement through our Website at least 30 days prior to the change taking effect by posting a notice on our home page or sending email to the primary email address specified in your account.</p>
<h2>Contact</h2>
<p>If you have any concerns about privacy, please contact us at <a href="mailto:privacy@your-gitea-instance">privacy@your-gitea-instance</a>. We will respond promptly, within 45 days.</p>
<h2>COPYING</h2>
<p>This document is licensed under <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0 Public Domain license</a>.</p>
<p>Thank you for choosing Your Gitea Instance! Before you use it, please read this Terms of Service agreement carefully, which contains important contract between us and our users.</p>
<h2>Definitions</h2>
<ol>
<li>An "Account" represents your legal relationship with Your Gitea Instance. A “User Account” represents an individual User’s authorization to log in to and use the Service and serves as a User’s identity on Your Gitea Instance. “Organizations” are shared workspaces that may be associated with a single entity or with one or more Users where multiple Users can collaborate across many projects at once. A User Account can be a member of any number of Organizations.</li>
<li>The "Agreement" collectively refers to all terms, conditions, and notices referenced or contained in this document and other operating rules, policies (including Privacy Policy) and procedures that we may publish from time to time on this Website.</li>
<li>“Content” refers to content featured or displayed through the Website, including without limitation code, text, data, articles, images, photographs, graphics, software, applications, packages, designs, features, and other materials that are available on the Website or otherwise available through the Service. "Content" also includes Services. “User-Generated Content” is Content, written or otherwise, created or uploaded by our Users. "Your Content" is Content that you create or own.</li>
<li>"Your Gitea Instance", "We", and "Us" refers to Your Gitea Instance, as well as our affiliates, directors, subsidiaries, contractors, licensors, officers, agents, and employees.</li>
<li>The "Service" refers to applications/software, products, and services provided by Your Gitea Instance.</li>
<li>The "User", "You", and "Your" refers to individual person or institution (organizations or company) that has visited or using the Service; that have access or use any part of the Account; or that directs to use the Account to perform its function. Please note that additional terms may apply for Accounts related to business or government.</li>
<li>The "Website" refers to Your Gitea Instance's website at <a href="https://your-gitea-instance">your-gitea-instance</a>, including its subdomains and other websites owned by Your Gitea Instance.</li>
</ol>
<h2>Account Terms</h2>
<h3>Account Controls</h3>
<ul>
<li>Users: Subject to these Terms, you retain ultimate administrative control over your User Account and the Content within it.</li>
<li>Organizations. The "owner" of an Organization that was created under these Terms has ultimate administrative control over that Organization and the Content within it. Within the Service, an owner can manage User access to the Organization’s data and projects. An Organization may have multiple owners, but there must be at least one User Account designated as an owner of an Organization. If you are the owner of an Organization under these Terms, we consider you responsible for the actions that are performed on or through that Organization.</li>
</ul>
<h3>Required Information</h3>
<p>You must provide a valid email address in order to complete the signup process. Any other information requested, such as your real name, is optional, unless you are accepting these terms on behalf of a legal entity (in which case we need more information about the legal entity).</p>
<h3>Account Requirements</h3>
<ul>
<li>You must be a human to create an Account. Accounts registered by "bots" or other automated methods are not permitted. We do permit machine accounts:</li>
<li>A machine account is an Account set up by an individual human who accepts the Terms on behalf of the Account, provides a valid email address, and is responsible for its actions. A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions.</li>
<li>You must be age 13 or older. If we learn of any User under that age, we will immediately terminate that User's Account. Different countries may have different minimum age; in such cases you are responsible for complying with your country's regulation. By using Your Gitea Instance, you agree to comply with <a href="https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule">COPPA</a> and/or similar law in your country.</li>
</ul>
<h3>User Account Security</h3>
<p>You are responsible for keeping your Account secure while you use our Service. We offer tools such as two-factor authentication to help you maintain your Account's security, but the content of your Account and its security are up to you.</p>
<h3>Additional Terms</h3>
<p>In some situations, third parties' terms may apply to your use of Your Gitea Instance. For example, you may be a member of an organization on Your Gitea Instance with its own terms or license agreements; you may download an application that integrates with Your Gitea Instance; or you may use Your Gitea Instance to authenticate to another service. Please be aware that while these Terms are our full agreement with you, other parties' terms govern their relationships with you.</p>
<h2>Acceptable Use</h2>
<p>Your use of the Website and Service must not violate any applicable laws, including copyright or trademark laws, export control or sanctions laws, or other laws in your jurisdiction. You are responsible for making sure that your use of the Service is in compliance with laws and any applicable regulations.</p>
<h2>User-Generated Content</h2>
<ol>
<li>You may create or upload User-Generated Content while using the Service. You are solely responsible for the content of, and for any harm resulting from, any User-Generated Content that you post, upload, link to or otherwise make available via the Service, regardless of the form of that Content. We are not responsible for any public display or misuse of your User-Generated Content.</li>
<li>We do not pre-screen User-Generated Content, but we have the right (though not the obligation) to refuse or remove any User-Generated Content that, in our sole discretion, violates any our terms or policies.</li>
<li>
<p>You retain ownership of and responsibility for Your Content. If you're posting anything you did not create yourself or do not own the rights to, you agree that you are responsible for any Content you post; that you will only submit Content that you have the right to post; and that you will fully comply with any third party licenses relating to Content you post.</p>
<p>Because of above, we need you to grant us -- and other Your Gitea Instance users -- certain legal permissions, listed below in this section. If you upload Content that already comes with a license granting Your Gitea Instance the permissions we need to run our Service, no additional license is required. You understand that you will not receive any payment for any of the rights granted below. The licenses you grant to us will end when you remove Your Content from our servers, unless other Users have forked it.</p>
</li>
<li>
<p>We need the legal right to do things like host Your Content, publish it, and share it. You grant us and our legal successors the right to store, parse, and display Your Content, and make incidental copies as necessary to render the Website and provide the Service. This includes the right to do things like copy it to our database and make backups; show it to you and other users; parse it into a search index or otherwise analyze it on our servers; share it with other users; and perform it, in case Your Content is something like music or video.</p>
<p>This license, however, doesn't grant Your Gitea Instance the right to sell Your Content or otherwise distribute or use it outside of our provision of the Service.</p>
</li>
<li>
<p>Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).</p>
<p>If you set your pages and repositories to be viewed publicly, you grant each User of Your Gitea Instance a nonexclusive, worldwide license to use, display, and perform Your Content through the Your Gitea Instance Service and to reproduce Your Content solely on Your Gitea Instance as permitted through Your Gitea Instance's functionality (for example, through forking). You may grant further rights if you adopt a license. If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other Your Gitea Instance Users.</p>
</li>
<li>
<p>Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supersede.</p>
<p><i>Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit.</i></p>
</li>
<li>
<p>You retain all moral rights to Your Content that you upload, publish, or submit to any part of the Service, including the rights of integrity and attribution. However, you waive these rights and agree not to assert them against us, to enable us to reasonably exercise the rights granted above, but not otherwise.</p>
<p>To the extent this agreement is not enforceable by applicable law, you grant Your Gitea Instance the rights we need to use Your Content without attribution and to make reasonable adaptations of Your Content as necessary to render the Website and provide the Service.</p>
</li>
</ol>
<h2>Private Repositories</h2>
<ol>
<li>Some Accounts may have private repositories, which allow the User to control access to Content.</li>
<li>Your Gitea Instance considers the contents of private repositories to be confidential to you. Your Gitea Instance will protect the contents of private repositories from unauthorized use, access, or disclosure in the same manner that we would use to protect our own confidential information of a similar nature and in no event with less than a reasonable degree of care.</li>
<li>
<p>Your Gitea Instance employees may only access the content of your private repositories in the following situations:</p>
<ul>
<li>With your consent and knowledge, for support reasons. If Your Gitea Instance accesses a private repository for support reasons, we will only do so with the owner’s consent and knowledge.</li>
<li>When access is required for security reasons, including when access is required to maintain ongoing confidentiality, integrity, availability and resilience of Your Gitea Instance's systems and Service.</li>
</ul>
</li>
<li>You may choose to enable additional access to your private repositories. For example: You may enable various Your Gitea Instance services or features that require additional rights to Your Content in private repositories. These rights may vary depending on the service or feature, but Your Gitea Instance will continue to treat your private repository Content as confidential. If those services or features require rights in addition to those we need to provide the Your Gitea Instance Service, we will provide an explanation of those rights.</li>
</ol>
<h2>Copyright Infringement and DMCA Policy</h2>
<p>If you are copyright owner and believe that content on our website violates your copyright, please contact us at <a href="mailto:copyright@your-gitea-instance">copyright@your-gitea-instance</a>. Please note that before sending a takedown notice, consider legal uses (such as fair use and licensed use); and legal consequences for sending false notices.</p>
<p>If you'd like to use our trademarks, you must follow all of our trademark guidelines.</p>
<p>This Agreement is licensed under <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO Public Domain License</a>.</p>
<h2>API Terms</h2>
<p>Abuse or excessively frequent requests to Your Gitea Instance via the API may result in the temporary or permanent suspension of your Account's access to the API. Your Gitea Instance, in our sole discretion, will determine abuse or excessive usage of the API. We will make a reasonable attempt to warn you via email prior to suspension.</p>
<p>You may not share API tokens to exceed Your Gitea Instance's rate limitations.</p>
<p>You may not use the API to download data or Content from Your Gitea Instance for spamming purposes, including for the purposes of selling Your Gitea Instance users' personal information, such as to recruiters, headhunters, and job boards.</p>
<p>All use of the Your Gitea Instance API is subject to these Terms of Service and the Your Gitea Instance Privacy Statement.</p>
<p>However, we may provide subscription-based access to our API for Users who need high-throughput access or reselling our Service.</p>
<h2>Cancellation and Termination</h2>
<h3>Account Cancellation</h3>
<p>It is your responsibility to properly cancel your Account with Your Gitea Instance. You can cancel your Account at any time by going into your Settings in the global navigation bar at the top of the screen. The Account screen provides a simple, no questions asked cancellation link. We are not able to cancel Accounts in response to an email or phone request.</p>
<h3>Upon Cancellation</h3>
<p>We will retain and use your information as necessary to comply with our legal obligations, resolve disputes, and enforce our agreements, but barring legal requirements, we will delete your full profile and the Content of your repositories within 90 days of cancellation or termination (though some information may remain in encrypted backups). This information can not be recovered once your Account is cancelled.</p>
<p>We will not delete Content that you have contributed to other Users' repositories or that other Users have forked.</p>
<p>Upon request, we will make a reasonable effort to provide an Account owner with a copy of your lawful, non-infringing Account contents after Account cancellation or termination. You must make this request within 90 days of cancellation or termination.</p>
<h3>We May Terminate</h3>
<p>Your Gitea Instance has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. Your Gitea Instance reserves the right to refuse service to anyone for any reason at any time.</p>
<h3>Survival</h3>
<p>All provisions of this Agreement which, by their nature, should survive termination will survive termination — including, without limitation: ownership provisions, warranty disclaimers, indemnity, and limitations of liability.</p>
<h2>Communications with Us</h2>
<h3>Electronic Communications Required</h3>
<p>For contractual purposes, you (1) consent to receive communications from us in an electronic form via the email address you have submitted or via the Service; and (2) agree that all Terms of Service, agreements, notices, disclosures, and other communications that we provide to you electronically satisfy any legal requirement that those communications would satisfy if they were on paper. This section does not affect your non-waivable rights.</p>
<h3>Legal Notices to Us Must Be in Writing</h3>
<p>Communications made through email or Your Gitea Instance Support's messaging system will not constitute legal notice to Your Gitea Instance or any of its officers, employees, agents or representatives in any situation where notice to Your Gitea Instance is required by contract or any law or regulation. Legal notice to Your Gitea Instance must be in writing and served on Your Gitea Instance's legal agent.</p>
<h3>No Phone Support</h3>
<p>We only offer support via email, in-Service communications, and electronic messages. We do not offer telephone support.</p>
<h2>Disclaimer of Warranties</h2>
<p>Your Gitea Instance provides the Website and the Service “as is” and “as available,” without warranty of any kind. Without limiting this, we expressly disclaim all warranties, whether express, implied or statutory, regarding the Website and the Service including without limitation any warranty of merchantability, fitness for a particular purpose, title, security, accuracy and non-infringement.</p>
<p>Your Gitea Instance does not warrant that the Service will meet your requirements; that the Service will be uninterrupted, timely, secure, or error-free; that the information provided through the Service is accurate, reliable or correct; that any defects or errors will be corrected; that the Service will be available at any particular time or location; or that the Service is free of viruses or other harmful components. You assume full responsibility and risk of loss resulting from your downloading and/or use of files, information, content or other material obtained from the Service.</p>
<h2>Limitation of Liability</h2>
<p>You understand and agree that we will not be liable to you or any third party for any loss of profits, use, goodwill, or data, or for any incidental, indirect, special, consequential or exemplary damages, however arising, that result from:</p>
<ul>
<li>the use, disclosure, or display of your User-Generated Content;</li>
<li>your use or inability to use the Service;</li>
<li>any modification, price change, suspension or discontinuance of the Service;</li>
<li>the Service generally or the software or systems that make the Service available;</li>
<li>unauthorized access to or alterations of your transmissions or data;</li>
<li>statements or conduct of any third party on the Service;</li>
<li>any other user interactions that you input or receive through your use of the Service; or
any other matter relating to the Service.</li>
</ul>
<p>Our liability is limited whether or not we have been informed of the possibility of such damages, and even if a remedy set forth in this Agreement is found to have failed of its essential purpose. We will have no liability for any failure or delay due to matters beyond our reasonable control.</p>
<h2>Release and Indemnification</h2>
<p>If you have a dispute with one or more Users, you agree to release Your Gitea Instance from any and all claims, demands and damages (actual and consequential) of every kind and nature, known and unknown, arising out of or in any way connected with such disputes.</p>
<p>You agree to indemnify us, defend us, and hold us harmless from and against any and all claims, liabilities, and expenses, including attorneys’ fees, arising out of your use of the Website and the Service, including but not limited to your violation of this Agreement, provided that Your Gitea Instance (1) promptly gives you written notice of the claim, demand, suit or proceeding; (2) gives you sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that you may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases Your Gitea Instance of all liability); and (3) provides to you all reasonable assistance, at your expense.</p>
<h2>Changes to These Terms</h2>
<p>We reserve the right, at our sole discretion, to amend these Terms of Service at any time and will update these Terms of Service in the event of any such amendments. We will notify our Users of material changes to this Agreement, such as price changes, at least 30 days prior to the change taking effect by posting a notice on our Website. For non-material modifications, your continued use of the Website constitutes agreement to our revisions of these Terms of Service.</p>
<h2>Miscellaneous</h2>
<h3>Governing Law</h3>
<p>Except to the extent applicable law provides otherwise, this Agreement between you and us and any access to or use of the Website or the Service are governed by (national laws of country/state where Gitea is deployed) and (regional laws of locality where Gitea is deployed), without regard to conflict of law provisions. You and Your Gitea Instance agree to submit to the exclusive jurisdiction and venue of the courts located in (locality where Gitea is deployed).</p>
<h3>Non-Assignability</h3>
<p>Your Gitea Instance may assign or delegate these Terms of Service and/or our Privacy Policy in whole or in part, to any person or entity at any time with or without your consent, including the license granted in <i>User-Generated Content</i>. You may not assign or delegate any rights or obligations under the Terms of Service or Privacy Statement without our prior written consent, and any unauthorized assignment and delegation by you is void.</p>
<h3>Severablity, No Waiver, and Survival</h3>
<p>If any part of this Agreement is held invalid or unenforceable, that portion of the Agreement will be construed to reflect the parties’ original intent. The remaining portions will remain in full force and effect. Any failure on the part of Your Gitea Instance to enforce any provision of this Agreement will not be considered a waiver of our right to enforce such provision. Our rights under this Agreement will survive any termination of this Agreement.</p>
<h3>Amendments and Complete Agreement</h3>
<p>This Agreement may only be modified by a written amendment signed by an authorized representative of Your Gitea Instance, or by the posting by Your Gitea Instance of a revised version in accordance with <i>Changes to These Terms</i>. These Terms of Service, together with the Your Gitea Instance Privacy Policy, represent the complete and exclusive statement of the agreement between you and us. This Agreement supersedes any proposal or prior agreement oral or written, and any other communications between you and Your Gitea Instance relating to the subject matter of these terms including any confidentiality or nondisclosure agreements.</p>
<h3>Contact</h3>
<p>If you have questions about these Terms of Service, you can <a href="mailto:support@your-gitea-instance">contact our support</a>.</p>
[](https://discord.gg/NsatcWJ)
[](https://discord.gg/Gitea)
[](http://microbadger.com/images/gitea/docs "Get your own image badge on microbadger.com")
Some jurisdictions (such as EU), requires certain legal pages (e.g. Privacy Policy) to be added to website. Follow these steps to add them to your Gitea instance.
## Getting Pages
Gitea source code ships with sample pages, available in `contrib/legal` directory. Copy them to `custom/public/`. For example, to add Privacy Policy:
Now you need to edit the page to meet your requirements. In particular you must change the email addresses, web addresses and references to "Your Gitea Instance" to match your situation.
You absolutely must not place a general ToS or privacy statement that implies that the gitea project is responsible for your server.
## Make it Visible
Create or append to `/path/to/custom/templates/custom/extra_links_footer.tmpl`:
**NOTE:** These tools are not endorsed by Gitea. They are listed here for convenience only.
## Hey! This page may be out of date or even removed in the future! :scream:
Instead, check out [awesome-gitea](https://gitea.com/gitea/awesome-gitea/src/branch/master/README.md#user-content-devops)!
## Listing
CI/CD solutions that have integration with Gitea. Following list is not complete,
@@ -30,5 +32,6 @@ the purpose is to give a starting point to integrate a CI/CD process with your G
- [Buildbot](https://www.buildbot.net/) with [Gitea plugin](https://github.com/lab132/buildbot-gitea)
Others CI/CD solutions that partially can be integrated with Gitea:
Others CI/CD solutions that can partially be integrated with Gitea:
- [Concourse](https://www.concourse-ci.org), see more information at [Concourse community forum](https://discuss.concourse-ci.org/t/concourse-ci-and-gitea-oauth/1475)
@@ -127,7 +128,9 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `DEFAULT_THEME`: **gitea**: \[gitea, arc-green\]: Set the default theme for the Gitea install.
- `THEMES`: **gitea,arc-green**: All available themes. Allow users select personalized themes
regardless of the value of `DEFAULT_THEME`.
- `REACTIONS`: All available reactions. Allow users react with different emoji's.
- `REACTIONS`: All available reactions users can choose on issues/prs and comments
Values can be emoji alias (:smile:) or a unicode emoji.
For custom reactions, add a tightly cropped square image to public/emoji/img/reaction_name.png
- `DEFAULT_SHOW_FULL_NAME`: **false**: Whether the full name of the users should be shown where possible. If the full name isn't set, the username will be used.
- `SEARCH_REPO_DESCRIPTION`: **true**: Whether to search within description at repository search on explore page.
- `USE_SERVICE_WORKER`: **true**: Whether to enable a Service Worker to cache frontend assets.
@@ -139,9 +142,19 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `NOTICE_PAGING_NUM`: **25**: Number of notices that are shown in one page.
- `ORG_PAGING_NUM`: **50**: Number of organizations that are shown in one page.
### UI - Notification (`ui.notification`)
- `MIN_TIMEOUT`: **10s**: These options control how often notification endpoint is polled to update the notification count. On page load the notification count will be checked after `MIN_TIMEOUT`. The timeout will increase to `MAX_TIMEOUT` by `TIMEOUT_STEP` if the notification count is unchanged. Set MIN_TIMEOUT to 0 to turn off.
- `MAX_TIMEOUT`: **60s**.
- `TIMEOUT_STEP`: **10s**.
- `EVENT_SOURCE_UPDATE_TIME`: **10s**: This setting determines how often the database is queried to update notification counts. If the browser client supports `EventSource`, it will be used in preference to polling notification endpoint.
## Markdown (`markdown`)
- `ENABLE_HARD_LINE_BREAK`: **false**: Enable Markdown's hard line break extension.
- `ENABLE_HARD_LINE_BREAK`: **true**: Render soft line breaks as hard line breaks, which
means a single newline character between paragraphs will cause a line break and adding
trailing whitespace to paragraphs is not necessary to force a line break.
- `CUSTOM_URL_SCHEMES`: Use a comma separated list (ftp,git,svn) to indicate additional
URL hyperlinks to be rendered in Markdown. URLs beginning in http and https are
always displayed
@@ -181,8 +194,8 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `SSH_LISTEN_PORT`: **%(SSH\_PORT)s**: Port for the built-in SSH server.
- `OFFLINE_MODE`: **false**: Disables use of CDN for static files and Gravatar for profile pictures.
- `DISABLE_ROUTER_LOG`: **false**: Mute printing of the router log.
- `CERT_FILE`: **custom/https/cert.pem**: Cert file path used for HTTPS.
- `KEY_FILE`: **custom/https/key.pem**: Key file path used for HTTPS.
- `CERT_FILE`: **https/cert.pem**: Cert file path used for HTTPS. From 1.11 paths are relative to `CUSTOM_PATH`.
- `KEY_FILE`: **https/key.pem**: Key file path used for HTTPS. From 1.11 paths are relative to `CUSTOM_PATH`.
- `STATIC_ROOT_PATH`: **./**: Upper level of template and static files path.
- `STATIC_CACHE_TIME`: **6h**: Web browser cache time for static resources on `custom/`, `public/` and all uploaded avatars.
@@ -191,6 +204,8 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `LFS_CONTENT_PATH`: **./data/lfs**: Where to store LFS files.
- `LFS_JWT_SECRET`: **\<empty\>**: LFS authentication secret, change this a unique string.
- `LFS_HTTP_AUTH_EXPIRY`: **20m**: LFS authentication validity period in time.Duration, pushes taking longer than this may fail.
- `LFS_MAX_FILE_SIZE`: **0**: Maximum allowed LFS file size in bytes (Set to 0 for no limit).
- `LFS_LOCK_PAGING_NUM`: **50**: Maximum number of LFS Locks returned per page.
- `REDIRECT_OTHER_PORT`: **false**: If true and `PROTOCOL` is https, allows redirecting http requests on `PORT_TO_REDIRECT` to the https port Gitea listens on.
- `PORT_TO_REDIRECT`: **80**: Port for the http redirection service to listen on. Used when `REDIRECT_OTHER_PORT` is true.
- `ENABLE_LETSENCRYPT`: **false**: If enabled you must set `DOMAIN` to valid internet facing domain (ensure DNS is set and port 80 is accessible by letsencrypt validation server).
@@ -209,7 +224,21 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
- `NAME`: **gitea**: Database name.
- `USER`: **root**: Database username.
- `PASSWD`: **\<empty\>**: Database user password. Use \`your password\` for quoting if you use special characters in the password.
-`SSL_MODE`: **disable**: For PostgreSQL and MySQL only.
-`SCHEMA`: **\<empty\>**: For PostgreSQL only, schema to use if different from "public". The schema must exist beforehand,
the user must have creation privileges on it, and the user search path must be set to the look into the schema first
(e.g. `ALTER USER user SET SEARCH_PATH = schema_name,"$user",public;`).
-`SSL_MODE`: **disable**: SSL/TLS encryption mode for connecting to the database. This option is only applied for PostgreSQL and MySQL.
- Valid values for MySQL:
-`true`: Enable TLS with verification of the database server certificate against its root certificate. When selecting this option make sure that the root certificate required to validate the database server certificate (e.g. the CA certificate) is on the system certificate store of both the database and Gitea servers. See your system documentation for instructions on how to add a CA certificate to the certificate store.
-`false`: Disable TLS.
-`disable`: Alias for `false`, for compatibility with PostgreSQL.
-`skip-verify`: Enable TLS without database server certificate verification. Use this option if you have self-signed or invalid certificate on the database server.
-`prefer`: Enable TLS with fallback to non-TLS connection.
- Valid values for PostgreSQL:
-`disable`: Disable TLS.
-`require`: Enable TLS without any verifications.
-`verify-ca`: Enable TLS with verification of the database server certificate against its root certificate.
-`verify-full`: Enable TLS and verify the database server name matches the given certificate in either the `Common Name` or `Subject Alternative Name` fields.
-`CHARSET`: **utf8**: For MySQL only, either "utf8" or "utf8mb4", default is "utf8". NOTICE: for "utf8mb4" you must use MySQL InnoDB > 5.6. Gitea is unable to check this.
-`PATH`: **data/gitea.db**: For SQLite3 only, the database file path.
-`LOG_SQL`: **true**: Log the executed SQL.
@@ -224,8 +253,10 @@ relation to port exhaustion.
## Indexer (`indexer`)
-`ISSUE_INDEXER_TYPE`: **bleve**: Issue indexer type, currently support: bleve or db, if it's db, below issue indexer item will be invalid.
-`ISSUE_INDEXER_PATH`: **indexers/issues.bleve**: Index file used for issue search.
-`ISSUE_INDEXER_TYPE`: **bleve**: Issue indexer type, currently supported: `bleve`, `db` or `elasticsearch`.
-`ISSUE_INDEXER_CONN_STR`: ****: Issue indexer connection string, available when ISSUE_INDEXER_TYPE is elasticsearch. i.e. http://elastic:changeme@localhost:9200
-`ISSUE_INDEXER_NAME`: **gitea_issues**: Issue indexer name, available when ISSUE_INDEXER_TYPE is elasticsearch
-`ISSUE_INDEXER_PATH`: **indexers/issues.bleve**: Index file used for issue search; available when ISSUE_INDEXER_TYPE is bleve and elasticsearch.
- The next 4 configuration values are deprecated and should be set in `queue.issue_indexer` however are kept for backwards compatibility:
-`ISSUE_INDEXER_QUEUE_TYPE`: **levelqueue**: Issue indexer queue, currently supports:`channel`, `levelqueue`, `redis`.
-`ISSUE_INDEXER_QUEUE_DIR`: **indexers/issues.queue**: When `ISSUE_INDEXER_QUEUE_TYPE` is `levelqueue`, this will be the queue will be saved path.
@@ -236,6 +267,7 @@ relation to port exhaustion.
-`REPO_INDEXER_PATH`: **indexers/repos.bleve**: Index file used for code search.
-`REPO_INDEXER_INCLUDE`: **empty**: A comma separated list of glob patterns (see https://github.com/gobwas/glob) to **include** in the index. Use `**.txt` to match any files with .txt extension. An empty list means include all files.
-`REPO_INDEXER_EXCLUDE`: **empty**: A comma separated list of glob patterns (see https://github.com/gobwas/glob) to **exclude** from the index. Files that match this list will not be indexed, even if they match in `REPO_INDEXER_INCLUDE`.
-`REPO_INDEXER_EXCLUDE_VENDORED`: **true**: Exclude vendored files from index.
-`UPDATE_BUFFER_LEN`: **20**: Buffer length of index request.
-`MAX_FILE_SIZE`: **1048576**: Maximum size in bytes of files to be indexed.
-`STARTUP_TIMEOUT`: **30s**: If the indexer takes longer than this timeout to start - fail. (This timeout will be added to the hammer time above for child processes - as bleve will not start until the previous parent is shutdown.) Set to zero to never timeout.
@@ -248,6 +280,10 @@ relation to port exhaustion.
-`BATCH_LENGTH`: **20**: Batch data before passing to the handler
-`CONN_STR`: **addrs=127.0.0.1:6379 db=0**: Connection string for the redis queue type.
-`QUEUE_NAME`: **_queue**: The suffix for default redis queue name. Individual queues will default to **`name`**`QUEUE_NAME` but can be overriden in the specific `queue.name` section.
-`SET_NAME`: **_unique**: The suffix that will added to the default redis
set name for unique queues. Individual queues will default to
**`name`**`QUEUE_NAME`_`SET_NAME`_ but can be overridden in the specific
`queue.name` section.
-`WRAP_IF_NECESSARY`: **true**: Will wrap queues with a timeoutable queue if the selected queue is not ready to be created - (Only relevant for the level queue.)
-`MAX_ATTEMPTS`: **10**: Maximum number of attempts to create the wrapped queue
-`TIMEOUT`: **GRACEFUL_HAMMER_TIME + 30s**: Timeout the creation of the wrapped queue if it takes longer than this to create.
@@ -309,7 +345,7 @@ relation to port exhaustion.
-`REQUIRE_EXTERNAL_REGISTRATION_PASSWORD`: **false**: Enable this to force externally created
accounts (via GitHub, OpenID Connect, etc) to create a password. Warning: enabling this will
decrease security, so you should only enable it if you know what you're doing.
-`REQUIRE_SIGNIN_VIEW`: **false**: Enable this to force users to log in to view any page.
-`REQUIRE_SIGNIN_VIEW`: **false**: Enable this to force users to log in to view any page or to use API.
-`ENABLE_NOTIFY_MAIL`: **false**: Enable this to send e-mail to watchers of a repository when
something happens, like creating issues. Requires `Mailer` to be enabled.
-`ENABLE_BASIC_AUTHENTICATION`: **true**: Disable this to disallow authenticaton using HTTP
@@ -375,10 +411,12 @@ relation to port exhaustion.
- Enabling dummy will ignore all settings except `ENABLED`, `SUBJECT_PREFIX` and `FROM`.
-`SENDMAIL_PATH`: **sendmail**: The location of sendmail on the operating system (can be
command or full path).
-`SENDMAIL_TIMEOUT`: **5m**: default timeout for sending email through sendmail
- ``IS_TLS_ENABLED`` : **false** : Decide if SMTP connections should use TLS.
## Cache (`cache`)
-`ENABLED`: **true**: Enable the cache.
-`ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, or `memcache`.
-`INTERVAL`: **60**: Garbage Collection interval (sec), for memory cache only.
-`HOST`: **\<empty\>**: Connection string for `redis` and `memcache`.
@@ -386,6 +424,12 @@ relation to port exhaustion.
- Memcache: `127.0.0.1:9090;127.0.0.1:9091`
-`ITEM_TTL`: **16h**: Time to keep items in cache if not used, Setting it to 0 disables caching.
@@ -501,7 +545,7 @@ NB: You must `REDIRECT_MACARON_LOG` and have `DISABLE_ROUTER_LOG` set to `false`
### Cron - Repository Health Check (`cron.repo_health_check`)
-`SCHEDULE`: **every 24h**: Cron syntax for scheduling repository health check.
-`SCHEDULE`: **@every 24h**: Cron syntax for scheduling repository health check.
-`TIMEOUT`: **60s**: Time duration syntax for health check execution timeout.
-`ARGS`: **\<empty\>**: Arguments for command `git fsck`, e.g. `--unreachable --tags`. See more on http://git-scm.com/docs/git-fsck
@@ -510,7 +554,7 @@ NB: You must `REDIRECT_MACARON_LOG` and have `DISABLE_ROUTER_LOG` set to `false`
-`RUN_AT_START`: **true**: Run repository statistics check at start time.
-`SCHEDULE`: **@every 24h**: Cron syntax for scheduling repository statistics check.
### Cron - Update Migration Poster ID (`cron.update_migration_post_id`)
### Cron - Update Migration Poster ID (`cron.update_migration_poster_id`)
-`SCHEDULE`: **@every 24h** : Interval as a duration between each synchronization, it will always attempt synchronization when the instance starts.
@@ -522,6 +566,9 @@ NB: You must `REDIRECT_MACARON_LOG` and have `DISABLE_ROUTER_LOG` set to `false`
-`MAX_GIT_DIFF_FILES`: **100**: Max number of files shown in diff view.
-`GC_ARGS`: **\<empty\>**: Arguments for command `git gc`, e.g. `--aggressive --auto`. See more on http://git-scm.com/docs/git-gc/
-`ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: If use git wire protocol version 2 when git version >= 2.18, default is true, set to false when you always want git wire protocol version 1
-`PULL_REQUEST_PUSH_MESSAGE`: **true**: Respond to pushes to a non-default branch with a URL for creating a Pull Request (if the repository has them enabled)
-`VERBOSE_PUSH`: **true**: Print status information about pushes as they are being processed.
-`VERBOSE_PUSH_DELAY`: **5s**: Only print verbose information if push takes longer than this delay.
-`ALLOW_ATTR`: The attribute this policy allows. Must be non-empty.
-`REGEXP`: A regex to match the contents of the attribute against. Must be present but may be empty for unconditional whitelisting of this attribute.
You may redefine `ELEMENT`, `ALLOW_ATTR`, and `REGEXP` multiple times; each time all three are defined is a single policy entry.
Multiple sanitisation rules can be defined by adding unique subsections, e.g. `[markup.sanitizer.TeX-2]`.
## Time (`time`)
@@ -633,10 +681,11 @@ You may redefine `ELEMENT`, `ALLOW_ATTR`, and `REGEXP` multiple times; each time
## Task (`task`)
-Task queue configuration has been moved to `queue.task` however, the below configuration values are kept for backwards compatibilityx:
Task queue configuration has been moved to `queue.task`. However, the below configuration values are kept for backwards compatibility:
-`QUEUE_TYPE`: **channel**: Task queue type, could be `channel` or `redis`.
-`QUEUE_LENGTH`: **1000**: Task queue length, available only when `QUEUE_TYPE` is `channel`.
-`QUEUE_CONN_STR`: **addrs=127.0.0.1:6379 db=0**: Task queue connection string, available only when `QUEUE_TYPE` is `redis`. If there redis needs a password, use `addrs=127.0.0.1:6379 password=123 db=0`.
-`QUEUE_CONN_STR`: **addrs=127.0.0.1:6379 db=0**: Task queue connection string, available only when `QUEUE_TYPE` is `redis`. If redis needs a password, use `addrs=127.0.0.1:6379 password=123 db=0`.
Customizing Gitea is typically done using the `CustomPath` folder - by default this is
the `custom` folder from the running directory, but may be different if your build has
set this differently. This is the central place to override configuration settings,
templates, etc. You can check the `CustomPath` using `gitea help`. You can override
templates, etc. You can check the `CustomPath` using `gitea help`. You can also find
the path on the _Configuration_ tab in the _Site Administration_ page. You can override
the `CustomPath` by setting either the `GITEA_CUSTOM` environment variable or by
using the `--custom-path` option on the `gitea` binary. (The option will override the
environment variable.)
@@ -56,14 +57,21 @@ the url `http://gitea.domain.tld/image.png`.
Place the png image at the following path: `custom/public/img/avatar_default.png`
## Customizing Gitea pages
## Customizing Gitea pages and resources
The `custom/templates` folder allows changing every single page of Gitea. Templates
to override can be found in the [`templates`](https://github.com/go-gitea/gitea/tree/master/templates) directory of Gitea source (Note: the example link is from `master` branch. Make sure to copy templates from same release you are using). Override by
making a copy of the file under `custom/templates` using a full path structure
matching source.
Gitea's executable contains all the resources required to run: templates, images, style-sheets
and translations. Any of them can be overridden by placing a replacement in a matching path
inside the `custom` directory. For example, to replace the default `.gitignore` provided
for C++ repositories, we want to replace `options/gitignore/C++`. To do this, a replacement
must be placed in `custom/options/gitignore/C++` (see about the location of the `custom`
directory at the top of this document).
Any statement contained inside `{{` and `}}` are Gitea's template syntax and
Every single page of Gitea can be changed. Dynamic content is generated using [go templates](https://golang.org/pkg/html/template/),
which can be modified by placing replacements below the `custom/templates` directory.
To obtain any embedded file (including templates), the [`gitea embedded` tool]({{< relref "doc/advanced/cmd-embedded.en-us.md" >}}) can be used. Alternatively, they can be found in the [`templates`](https://github.com/go-gitea/gitea/tree/master/templates) directory of Gitea source (Note: the example link is from the `master` branch. Make sure to use templates compatible with the release you are using).
Be aware that any statement contained inside `{{` and `}}` are Gitea's template syntax and
shouldn't be touched without fully understanding these components.
### Customizing startpage / homepage
@@ -82,6 +90,8 @@ just place it under your "custom/public/" directory (for instance `custom/public
To match the current style, the link should have the class name "item", and you can use `{{AppSubUrl}}` to get the base URL:
You also need to download the content of the library [Madeleine.js](https://jinjunho.github.io/Madeleine.js/) and place it under `custom/public/` folder.
You should end-up with a folder structucture similar to:
```
custom/templates
-- custom
`-- footer.tmpl
custom/public
-- Madeleine.js
|-- LICENSE
|-- README.md
|-- css
| |-- pygment_trac.css
| `-- stylesheet.css
|-- examples
| |-- ajax.html
| |-- index.html
| `-- upload.html
|-- images
| |-- bg_hr.png
| |-- blacktocat.png
| |-- icon_download.png
| `-- sprite_download.png
|-- models
| |-- dino2.stl
| |-- ducati.stl
| |-- gallardo.stl
| |-- lamp.stl
| |-- octocat.stl
| |-- skull.stl
| `-- treefrog.stl
`-- src
|-- Madeleine.js
|-- css
| `-- Madeleine.css
|-- icons
| |-- logo.png
| |-- madeleine.eot
| |-- madeleine.svg
| |-- madeleine.ttf
| `-- madeleine.woff
`-- lib
|-- MadeleineConverter.js
|-- MadeleineLoader.js
|-- detector.js
|-- stats.js
`-- three.min.js
```
Then restart gitea and open a STL file on your gitea instance.
## Customizing Gitea mails
The `custom/templates/mail` folder allows changing the body of every mail of Gitea.
@@ -110,8 +275,6 @@ full path structure matching source.
Any statement contained inside `{{` and `}}` are Gitea's template
syntax and shouldn't be touched without fully understanding these components.
## Adding Analytics to Gitea
Google Analytics, Matomo (previously Piwik), and other analytics services can be added to Gitea. To add the tracking code, refer to the `Other additions to the page` section of this document, and add the JavaScript to the `custom/templates/custom/header.tmpl` file.
@@ -155,6 +318,9 @@ Locales may change between versions, so keeping track of your customized locales
To add a custom Readme, add a markdown formatted file (without an `.md` extension) to `custom/options/readme`
**NOTE:** readme templates support **variable expansion**.
currently there are `{Name}` (name of repository), `{Description}`, `{CloneURL.SSH}`, `{CloneURL.HTTPS}` and `{OwnerName}`
### Reactions
To change reaction emoji's you can set allowed reactions at app.ini
This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](../customizing-gitea) page.
## Installing external binaries
In order to get file rendering through external binaries, their associated packages must be installed.
@@ -34,7 +36,7 @@ FROM gitea/gitea:{{< version >}}
# install any other package you need for your external renderers
RUN pip3 install --upgrade pip
@@ -71,7 +73,7 @@ IS_INPUT_FILE = false
If your external markup relies on additional classes and attributes on the generated HTML elements, you might need to enable custom sanitizer policies. Gitea uses the [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) package as our HTML sanitizier. The example below will support [KaTeX](https://katex.org/) output from [`pandoc`](https://pandoc.org/).
```ini
[markup.sanitizer]
[markup.sanitizer.TeX]
; Pandoc renders TeX segments as <span>s with the "math" class, optionally
; with "inline" or "display" classes depending on context.
You may redefine `ELEMENT`, `ALLOW_ATTR`, and `REGEXP`multiple times; each time all three are defined is a single policy entry. All three must be defined, but `REGEXP` may be blank to allow unconditional whitelisting of that attribute.
You must define `ELEMENT`, `ALLOW_ATTR`, and `REGEXP`in each section.
To define multiple entries, add a unique alphanumeric suffix (e.g., `[markup.sanitizer.1]` and `[markup.sanitizer.something]`).
Once your configuration changes have been made, restart Gitea to have changes take effect.
**Note**: Prior to Gitea 1.12 there was a single `markup.sanitiser` section with keys that were redefined for multiple rules, however,
there were significant problems with this method of configuration necessitating configuration through multiple sections.
@@ -105,16 +91,11 @@ The simplest recommended way to build from source is:
TAGS="bindata sqlite sqlite_unlock_notify" make build
```
However, there are a number of additional make tasks you should be aware of.
These are documented below but you can look at our
[`Makefile`](https://github.com/go-gitea/gitea/blob/master/Makefile) for more,
and look at our
[`.drone.yml`](https://github.com/go-gitea/gitea/blob/master/.drone.yml) to see
how our continuous integration works.
See `make help` for all available `make` tasks. Also see [`.drone.yml`](https://github.com/go-gitea/gitea/blob/master/.drone.yml) to see how our continuous integration works.
### Formatting, code analysis and spell check
Our continous integration will reject PRs that are not properly formatted, fail
Our continuous integration will reject PRs that are not properly formatted, fail
code analysis or spell check.
You should format your code with `go fmt` using:
@@ -140,23 +121,40 @@ You should run revive, vet and spell-check on the code with:
make revive vet misspell-check
```
### Working on CSS
### Working on JS and CSS
Edit files in `web_src/less` and run the linter and build the CSS files via:
For simple changes, edit files in `web_src`, run the build and start the server to test:
```bash
make css
make build && ./gitea
```
### Working on JS
`make build` runs both `make frontend` and `make backend` which can be run individually as well as long as the `bindata` tag is not used (which compiles frontend files into the binary).
Edit files in `web_src/js`, run the linter and build the JS files via:
For more involved changes use the `watch-frontend` task to continuously rebuild files when their sources change. The `bindata` tag must be absent. First, build and run the backend:
```bash
make js
make backend && ./gitea
```
Note: When working on frontend code, it is advisable to set `USE_SERVICE_WORKER` to `false` in `app.ini` which will prevent undesirable caching of frontend assets.
With the backend running, open another terminal and run:
```bash
make watch-frontend
```
Before committing, make sure the linters pass:
```bash
make lint-frontend
```
Note: When working on frontend code, set `USE_SERVICE_WORKER` to `false` in `app.ini` to prevent undesirable caching of frontend assets.
### Building Images
To build the images, ImageMagick, `inkscape` and `zopflipng` binaries must be available in
your `PATH` to run `make generate-images`.
### Updating the API
@@ -240,8 +238,9 @@ have written integration tests; however, these are database dependent.
TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
```
will run the integration tests in an sqlite environment. Other database tests
are available but may need adjustment to the local environment.
will run the integration tests in an sqlite environment. Integration tests
require `git lfs` to be installed. Other database tests are available but
@@ -42,6 +42,8 @@ Gitea applies glob pattern matching from the [`gobwas/glob` library](https://git
Limiting the list of files prevents the indexes from becoming polluted with derived or irrelevant files (e.g. lss, sym, map, etc.), so the search results are more relevant. It can also help reduce the index size.
`REPO_INDEXER_EXCLUDE_VENDORED` (default: true) excludes vendored files from index.
`REPO_INDEXER_INCLUDE` (default: empty) is a comma separated list of glob patterns to **include** in the index. An empty list means "_include all files_".
`REPO_INDEXER_EXCLUDE` (default: empty) is a comma separated list of glob patterns to **exclude** from the index. Files that match this list will not be indexed. `REPO_INDEXER_EXCLUDE` takes precedence over `REPO_INDEXER_INCLUDE`.
[GitNex for Android](https://gitlab.com/mmarif4u/gitnex)
-[GitNex for Android](https://gitlab.com/mmarif4u/gitnex)
### Editor Extensions
- [Gitea Extension for Visual Studio](https://github.com/maikebing/Gitea.VisualStudio) Download from [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=MysticBoy.GiteaExtensionforVisualStudio)
- [Gitea Extension for Visual Studio](https://github.com/maikebing/Gitea.VisualStudio)
- Download from [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=MysticBoy.GiteaExtensionforVisualStudio)
### Project Management
- [YouTrack by JetBrains](https://blog.jetbrains.com/youtrack/2019/12/whats-new-in-youtrack-2019-3/)
Gitea repositories can include a `.gitea` directory at their base which will store settings/configurations for certain features.
## Templates
Gitea includes template repositories, and one feature implemented with them is auto-expansion of specific variables within your template files.
To tell Gitea which files to expand, you must include a `template` file inside the `.gitea` directory of the template repository.
Gitea uses [gobwas/glob](https://github.com/gobwas/glob) for its glob syntax. It closely resembles a traditional `.gitignore`, however there may be slight differences.
### Example `.gitea/template` file
All paths are relative to the base of the repository
```gitignore
# All .go files, anywhere in the repository
**.go
# All text files in the text directory
text/*.txt
# A specific file
a/b/c/d.json
# Batch files in both upper or lower case can be matched
**.[bB][aA][tT]
```
**NOTE:** The `template` file will be removed from the `.gitea` directory when a repository is generated from the template.
### Variable Expansion
In any file matched by the above globs, certain variables will be expanded.
All variables must be of the form `$VAR` or `${VAR}`. To escape an expansion, use a double `$$`, such as `$$VAR` or `$${VAR}`
Gitea's localization happens through our [Crowdin project](https://crowdin.com/project/gitea).
For changes to an **English** translation, a pull request can be made that changes the appropriate key in
the [english locale](https://github.com/go-gitea/gitea/blob/master/options/locale/locale_en-US.ini).
For changes to a **non-English** translation, refer to the Crowdin project above.
## Supported Languages
Any language listed in the above Crowdin project will be supported as long as 25% or more has been translated.
After a translation has been accepted, it will be reflected in the main repository after the next Crowdin sync, which is generally after any PR is merged.
At the time of writing, this means that a changed translation may not appear until the following Gitea release.
If you use a bleeding edge build, it should appear as soon as you update after the change is synced.
To migrate from Gitlab to Gitea, you can use this non-affiliated tool:
https://github.com/loganinak/MigrateGitlabToGogs
@@ -147,6 +151,14 @@ You can configure `WHITELISTED_URIS` or `BLACKLISTED_URIS` under `[openid]` in y
### Issue only users
The current way to achieve this is to create/modify a user with a max repo creation limit of 0.
### Restricted users
Restricted users are limited to a subset of the content based on their organization/team memberships and collaborations, ignoring the public flag on organizations/repos etc.__
Example use case: A company runs a Gitea instance that requires login. Most repos are public (accessible/browseable by all co-workers).
At some point, a customer or third party needs access to a specific repo and only that repo. Making such a customer account restricted and granting any needed access using team membership(s) and/or collaboration(s) is a simple way to achieve that without the need to make everything private.
### Enable Fail2ban
Use [Fail2Ban]({{ relref "doc/usage/fail2ban-setup.md" >}}) to monitor and stop automated login attempts or other malicious behavior based on log patterns
@@ -291,3 +303,8 @@ There is no setting for password resets. It is enabled when a [mail service]({{<
- In your account `Settings -> Account` page (this method **requires** you to know your current password).
- By using the `Forgot Password` link.
If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service]({{< relref "doc/usage/email-setup.en-us.md" >}}).
## Why is my markdown broken
In Gitea version `1.11` we moved to [goldmark](https://github.com/yuin/goldmark) for markdown rendering, which is [CommonMark](https://commonmark.org/) compliant.
If you have markdown that worked as you expected prior to version `1.11` and after upgrading it's not working anymore, please look through the CommonMark spec to see whether the problem is due to a bug or non-compliant syntax.
If it is the latter, _usually_ there is a compliant alternative listed in the spec.
You need a database to use Gitea. Gitea supports PostgreSQL, MySQL, SQLite, and MSSQL. This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production.
Database instance can be on same machine as Gitea (local database setup), or on different machine (remote database).
Note: All steps below requires that the database engine of your choice is installed on your system. For remote database setup, install the server part on database instance and client part on your Gitea server. In addition, make sure you use same engine version for both server and client for some engine features to work. For security reason, protect `root` (MySQL) or `postgres` (PostgreSQL) database superuser with secure password. The steps assumes that you run Linux for both database and Gitea servers.
## MySQL
1. On database instance, login to database console as root:
```
mysql -u root -p
```
Enter the password as prompted.
2. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
For local database:
```sql
SET old_passwords=0;
CREATE USER 'gitea' IDENTIFIED BY 'gitea';
```
For remote database:
```sql
SET old_passwords=0;
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
```
where `192.0.2.10` is the IP address of your Gitea instance.
Replace username and password above as appropriate.
3. Create database with UTF-8 charset and collation. Make sure to use `utf8mb4` charset instead of `utf8` as the former supports all Unicode characters (including emojis) beyond *Basic Multilingual Plane*. Also, collation chosen depending on your expected content. When in doubt, use either `unicode_ci` or `general_ci`.
```sql
CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
```
Replace database name as appropriate.
4. Grant all privileges on the database to database user created above.
For local database:
```sql
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
FLUSH PRIVILEGES;
```
For remote database:
```sql
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10';
FLUSH PRIVILEGES;
```
5. Quit from database console by `exit`.
6. On your Gitea server, test connection to the database:
```
mysql -u gitea -h 203.0.113.3 -p giteadb
```
where `gitea` is database username, `giteadb` is database name, and `203.0.113.3` is IP address of database instance. Omit `-h` option for local database.
You should be connected to the database.
## PostgreSQL
1. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
```ini
password_encryption = scram-sha-256
```
Restart PostgreSQL to apply the setting.
2. On the database server, login to the database console as superuser:
```
su -c "psql" - postgres
```
3. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
```sql
CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
```
Replace username and password as appropriate.
4. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
5. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
For local database:
```ini
local giteadb gitea scram-sha-256
```
For remote database:
```ini
host giteadb gitea 192.0.2.10/32 scram-sha-256
```
Replace database name, user, and IP address of Gitea instance with your own.
Note: rules on `pg_hba.conf` are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case.
Restart PostgreSQL to apply new authentication rules.
6. On your Gitea server, test connection to the database.
For local database:
```
psql -U gitea -d giteadb
```
For remote database:
```
psql "postgres://gitea@203.0.113.3/giteadb"
```
where `gitea` is database user, `giteadb` is database name, and `203.0.113.3` is IP address of your database instance.
You should be prompted to enter password for the database user, and connected to the database.
## Database Connection over TLS
If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.
### Prerequisites
- You need two valid TLS certificates, one for the database instance (database server) and one for the Gitea instance (database client). Both certificates must be signed by a trusted CA.
- The database certificate must contain `TLS Web Server Authentication` in the `X509v3 Extended Key Usage` extension attribute, while the client certificate needs `TLS Web Client Authentication` in the corresponding attribute.
- On the database server certificate, one of `Subject Alternative Name` or `Common Name` entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. `db.example.com`). On the database client certificate, one of the entries mentioned above must contain the database username that Gitea will be using to connect.
- You need domain name mappings of both Gitea and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to `/etc/hosts` (`%WINDIR%\System32\drivers\etc\hosts` in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details.
### PostgreSQL
The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.
1. On the server with the database instance, place the following credentials:
You should be prompted to enter password for the database user, and then be connected to the database.
### MySQL
While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently supports only one-way TLS. See issue #10828 for details.
In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place.
1. On the database instance, place the following credentials:
5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
```sql
DROP USER 'gitea'@'192.0.2.10';
CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL;
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea';
FLUSH PRIVILEGES;
```
Replace database user name, password, and Gitea instance domain as appropriate.
6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
7. On the server running Gitea, test connection to the database:
Gitea signs all binaries with a [GPG key](https://pgp.mit.edu/pks/lookup?op=vindex&fingerprint=on&search=0x2D9AE806EC1592E2) to prevent against unwanted modification of binaries. To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the gpg command line tool.
Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries. To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the gpg command line tool.
gpg --verify gitea-{{< version >}}-linux-amd64.asc gitea-{{< version >}}-linux-amd64
```
## Test
After getting a binary, it can be tested with `./gitea web` or moved to a permanent
location. When launched manually, Gitea can be killed using `Ctrl+C`.
```
./gitea web
```
## Recommended server configuration
**NOTE:** Many of the following directories can be configured using [Environment Variables]({{< relref "doc/advanced/specific-variables.en-us.md" >}}) as well!
@@ -122,6 +113,18 @@ It is recommended you do a [backup]({{< relref "doc/usage/backup-and-restore.en-
If you have carried out the installation steps as described above, the binary should
have the generic name `gitea`. Do not change this, i.e. to include the version number.
### 1. Restarting gitea with systemd (recommended)
As explained before, we recommend to use systemd as service manager. In this case ```systemctl restart gitea``` should be enough.
### 2. Restarting gitea without systemd
To restart your gitea instance, we recommend to use SIGHUP signal. If you know your gitea PID use ```kill -1 $GITEA_PID``` otherwise you can use ```killall -1 gitea``` or ```pkill -1 gitea```
To gracefully stop the gitea instance, a simple ```kill $GITEA_PID``` or ```killall gitea``` is enough.
**NOTE:** We don't recommend to use SIGKILL signal (know also as `-9`), you may be forcefully stopping some of Gitea internal tasks and it will not gracefully stop (tasks in queues, indexers processes, etc.)
See below for troubleshooting instructions to repair broken repositories after
@@ -42,4 +42,4 @@ Si vous obtenez l'erreur `702 runWeb()] [E] Failed to start server: listen tcp 0
## Il manque quelque chose ?
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/NsatcWJ), vous obtiendrez des réponses à toute vos questions assez rapidement.
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement.
@@ -54,4 +54,4 @@ Pour exécuter Gitea en tant que service, utilisez la commande `sysrc gitea_enab
## Il manque quelque chose ?
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/NsatcWJ), vous obtiendrez des réponses à toute vos questions assez rapidement.
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement.
@@ -23,7 +23,7 @@ environment variable and to add the go bin directory or directories
Next, [install Node.js with npm](https://nodejs.org/en/download/) which is
required to build the JavaScript and CSS files. The minimum supported Node.js
version is 10 and the latest LTS version is recommended.
version is {{<min-node-version>}} and the latest LTS version is recommended.
**Note**: When executing make tasks that require external tools, like
`make misspell-check`, Gitea will automatically download and build these as
@@ -31,24 +31,24 @@ necessary. To be able to use these, you must have the `"$GOPATH/bin"` directory
on the executable path. If you don't add the go bin directory to the
executable path, you will have to manage this yourself.
**Note 2**: Go version 1.11 or higher is required. However, it is recommended to
**Note 2**: Go version {{<min-go-version>}} or higher is required. However, it is recommended to
obtain the same version as our continuous integration, see the advice given in
<ahref='{{< relref "doc/advanced/hacking-on-gitea.en-us.md" >}}'>Hacking on
Gitea</a>
## Download
First, retrieve the source code. The easiest way is to use the Go tool. Use the
following commands to fetch the source and switch into the source directory.
Go is quite opinionated about where it expects its source code, and simply
cloning the Gitea repository to an arbitrary path is likely to lead to
problems - the fixing of which is out of scope for this document.
First, we must retrieve the source code. Since, the advent of go modules, the
simplest way of doing this is to use git directly as we no longer have to have
gitea built from within the GOPATH.
```bash
go get -d -u code.gitea.io/gitea
cd"$GOPATH/src/code.gitea.io/gitea"
git clone https://github.com/go-gitea/gitea
```
(Previous versions of this document recommended using `go get`. This is
no longer necessary.)
Decide which version of Gitea to build and install. Currently, there are
multiple options to choose from. The `master` branch represents the current
development version. To build with master, skip to the [build section](#build).
@@ -81,8 +81,8 @@ git checkout v{{< version >}} # or git checkout pr-xyz
To build from source, the following programs must be present on the system:
-`go`1.11.0 or higher, see [here](https://golang.org/dl/)
-`node`10.0.0 or higher with `npm`, see [here](https://nodejs.org/en/download/)
-`go`{{<min-go-version>}} or higher, see [here](https://golang.org/dl/)
-`node`{{<min-node-version>}} or higher with `npm`, see [here](https://nodejs.org/en/download/)
-`make`, see <ahref='{{< relref "doc/advanced/make.en-us.md" >}}'>here</a>
Various [make tasks](https://github.com/go-gitea/gitea/blob/master/Makefile)
@@ -114,6 +114,17 @@ recommended way to build from source is therefore:
TAGS="bindata sqlite sqlite_unlock_notify" make build
```
The `build` target is split into two sub-targets:
-`make backend` which requires [Go {{< min-go-version >}}](https://golang.org/dl/) or greater.
-`make frontend` which requires [Node.js {{< min-node-version >}}](https://nodejs.org/en/download/) or greater.
If pre-built frontend files are present it is possible to only build the backend:
```bash
TAGS="bindata" make backend
```
## Test
After following the steps above, a `gitea` binary will be available in the working directory.
@@ -146,3 +157,23 @@ Add as many of the strings with their preceding `-X` to the `LDFLAGS` variable a
with the appropriate `TAGS` as above.
Running `gitea help` will allow you to review what the computed settings will be for your `gitea`.
## Cross Build
The `go` compiler toolchain supports cross-compiling to different architecture targets that are supported by the toolchain. See [`GOOS` and `GOARCH` environment variable](https://golang.org/doc/install/source#environment) for the list of supported targets. Cross compilation is helpful if you want to build Gitea for less-powerful systems (such as Raspberry Pi).
To cross build Gitea with build tags (`TAGS`), you also need a C cross compiler which targets the same architecture as selected by the `GOOS` and `GOARCH` variables. For example, to cross build for Linux ARM64 (`GOOS=linux` and `GOARCH=arm64`), you need the `aarch64-unknown-linux-gnu-gcc` cross compiler. This is required because Gitea build tags uses `cgo`'s foreign-function interface (FFI).
Cross-build Gitea for Linux ARM64, without any tags:
```
GOOS=linux GOARCH=arm64 make build
```
Cross-build Gitea for Linux ARM64, with recommended build tags:
```
CC=aarch64-unknown-linux-gnu-gcc GOOS=linux GOARCH=arm64 TAGS="bindata sqlite sqlite_unlock_notify" make build
```
Replace `CC`, `GOOS`, and `GOARCH` as appropriate for your architecture target.
@@ -76,4 +76,4 @@ Après avoir suivi toutes les étapes, vous devriez avoir le binaire `gitea` dan
## Il manque quelque chose ?
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/NsatcWJ), vous obtiendrez des réponses à toute vos questions assez rapidement.
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement.
You can run Gitea as service, using either systemd or supervisor. The steps below tested on Ubuntu 16.04, but those should work on any Linux distributions (with little modification).
#### Using systemd
Run the below command in a terminal:
```
sudo vim /etc/systemd/system/gitea.service
```
Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service).
Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
Uncomment any service that needs to be enabled on this host, such as MySQL.
@@ -35,6 +32,10 @@ sudo systemctl enable gitea
sudo systemctl start gitea
```
If you have systemd version 220 or later, you can enable and immediately start Gitea at once by:
```
sudo systemctl enable gitea --now
```
#### Using supervisor
@@ -49,19 +50,20 @@ Create a log dir for the supervisor logs:
@@ -253,7 +253,8 @@ You can configure some of Gitea's settings via environment variables:
*`APP_NAME`: **"Gitea: Git with a cup of tea"**: Application name, used in the page title.
*`RUN_MODE`: **dev**: For performance and other purposes, change this to `prod` when deployed to a production environment.
*`SSH_DOMAIN`: **localhost**: Domain name of this server, used for the displayed clone URL in Gitea's UI.
*`DOMAIN`: **localhost**: Domain name of this server, used for the displayed http clone URL in Gitea's UI.
*`SSH_DOMAIN`: **localhost**: Domain name of this server, used for the displayed ssh clone URL in Gitea's UI. If the install page is enabled, SSH Domain Server takes DOMAIN value in the form (which overwrite this setting on save).
*`SSH_PORT`: **22**: SSH port displayed in clone URL.
*`SSH_LISTEN_PORT`: **%(SSH\_PORT)s**: Port for the built-in SSH server.
*`DISABLE_SSH`: **false**: Disable SSH feature when it's not available.
@@ -107,4 +107,4 @@ Le fichier de configuration sera sauvegardé à l'emplacement suivant : `/data/g
## Il manque quelque chose ?
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/NsatcWJ), vous obtiendrez des réponses à toute vos questions assez rapidement.
Est-ce que nous avons oublié quelque chose sur cette page ? N'hésitez pas à nous contacter sur notre [serveur Discord](https://discord.gg/Gitea), vous obtiendrez des réponses à toute vos questions assez rapidement.
-`--user-search-base value`: The LDAP base at which user accounts will be searched for. Required.
-`--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. Required.
-`--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
-`--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
-`--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
-`--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
-`--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
@@ -158,6 +159,7 @@ Admin operations:
-`--user-search-base value`: The LDAP base at which user accounts will be searched for.
-`--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate.
-`--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
-`--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
-`--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
-`--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
-`--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
@@ -182,6 +184,7 @@ Admin operations:
-`--user-search-base value`: The LDAP base at which user accounts will be searched for.
-`--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. Required.
-`--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
-`--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
-`--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
-`--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
-`--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
@@ -202,6 +205,7 @@ Admin operations:
-`--user-search-base value`: The LDAP base at which user accounts will be searched for.
-`--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate.
-`--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
-`--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
-`--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
-`--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
-`--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
@@ -289,3 +293,28 @@ This command is idempotent.
#### convert
Converts an existing MySQL database from utf8 to utf8mb4.
#### doctor
Diagnose the problems of current gitea instance according the given configuration.
Currently there are a check list below:
- Check if OpenSSH authorized_keys file id correct
When your gitea instance support OpenSSH, your gitea instance binary path will be written to `authorized_keys`
when there is any public key added or changed on your gitea instance.
Sometimes if you moved or renamed your gitea binary when upgrade and you haven't run `Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.)` on your Admin Panel. Then all pull/push via SSH will not be work.
This check will help you to check if it works well.
For contributors, if you want to add more checks, you can wrie ad new function like `func(ctx *cli.Context) ([]string, error)` and
append it to `doctor.go`.
```go
varchecklist=[]check{
{
title:"Check if OpenSSH authorized_keys file id correct",
f:runDoctorLocationMoved,
},
// more checks please append here
}
```
This function will receive a command line context and return a list of details about the problems or error.
Note: Enabling HTTPS only at the proxy level is referred as [TLS Termination Proxy](https://en.wikipedia.org/wiki/TLS_termination_proxy). The proxy server accepted incoming TLS connections, decrypts the contents, and pass the now unencrypted contents to Gitea. This is normally fine as long as both the proxy and Gitea instances are either on the same machine, or on different machines within private network (with the proxy is exposed to outside network. If your Gitea instance is separated from your proxy over a public network, or if you want full end-to-end encryption, you can also [enable HTTPS support directly in Gitea using built-in server](#using-the-built-in-server) and forward the connections over HTTPS instead.
Note: Enabling HTTPS only at the proxy level is referred as [TLS Termination Proxy](https://en.wikipedia.org/wiki/TLS_termination_proxy). The proxy server accepts incoming TLS connections, decrypts the contents, and passes the now unencrypted contents to Gitea. This is normally fine as long as both the proxy and Gitea instances are either on the same machine, or on different machines within private network (with the proxy is exposed to outside network). If your Gitea instance is separated from your proxy over a public network, or if you want full end-to-end encryption, you can also [enable HTTPS support directly in Gitea using built-in server](#using-the-built-in-server) and forward the connections over HTTPS instead.
@@ -54,9 +54,9 @@ Nginx can serve static resources directly and proxy only the dynamic requests to
Nginx is optimized for serving static content, while the proxying of large responses might be the opposite of that
(see https://serverfault.com/q/587386).
Download a snapshot of the gitea source repository to `/path/to/gitea/`.
We are only interested in the `public/` directory and you can delete the rest.
Download a snapshot of the Gitea source repository to `/path/to/gitea/`.
After this, run `make webpack` in the repository directory to generate the static resources. We are only interested in the `public/` directory for this task, so you can delete the rest.
(You will need to have [Node with npm](https://nodejs.org/en/download/) and `make` installed to generate the static resources)
Depending on the scale of your user base, you might want to split the traffic to two distinct servers,
or use a cdn for the static files.
@@ -174,3 +174,59 @@ git.example.com {
```
Then set `[server] ROOT_URL = http://git.example.com/git/` in your configuration.
## Using IIS as a reverse proxy
If you wish to run Gitea with IIS. You will need to setup IIS with URL Rewrite as reverse proxy.
1. Setup an empty website in IIS, named let's say, `Gitea Proxy`.
2. Follow the first two steps in [Microsoft's Technical Community Guide to Setup IIS with URL Rewrite](https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222#M343). That is:
- Install Application Request Routing (ARR for short) either by using the Microsoft Web Platform Installer 5.1 (WebPI) or downloading the extension from [IIS.net]( https://www.iis.net/downloads/microsoft/application-request-routing)
- Once the module is installed in IIS, you will see a new Icon in the IIS Administration Console called URL Rewrite.
- Open the IIS Manager Console and click on the `Gitea Proxy` Website from the tree view on the left. Select and double click the URL Rewrite Icon from the middle pane to load the URL Rewrite interface.
- Choose the `Add Rule` action from the right pane of the management console and select the `Reverse Proxy Rule` from the `Inbound and Outbound Rules` category.
- In the Inbound Rules section, set the server name to be the host that Gitea is running on with its port. e.g. if you are running Gitea on the localhost with port 3000, the following should work: `127.0.0.1:3000`
- Enable SSL Offloading
- In the Outbound Rules, ensure `Rewrite the domain names of the links in HTTP response` is set and set the `From:` field as above and the `To:` to your external hostname, say: `git.example.com`
- Now edit the `web.config` for your website to match the following: (changing `127.0.0.1:3000` and `git.example.com` as appropriate)
Gitea `1.11.0` and above includes template repositories, and one feature implemented with them is auto-expansion of specific variables within your template files.
To tell Gitea which files to expand, you must include a `template` file inside the `.gitea` directory of the template repository.
Gitea uses [gobwas/glob](https://github.com/gobwas/glob) for its glob syntax. It closely resembles a traditional `.gitignore`, however there may be slight differences.
### Example `.gitea/template` file
All paths are relative to the base of the repository
```gitignore
# All .go files, anywhere in the repository
**.go
# All text files in the text directory
text/*.txt
# A specific file
a/b/c/d.json
# Batch files in both upper or lower case can be matched
**.[bB][aA][tT]
```
**NOTE:** The `template` file will be removed from the `.gitea` directory when a repository is generated from the template.
### Variable Expansion
In any file matched by the above globs, certain variables will be expanded.
All variables must be of the form `$VAR` or `${VAR}`. To escape an expansion, use a double `$$`, such as `$$VAR` or `$${VAR}`
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.