| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
upstream
|
|
|
|
| |
only copr-service is (user under which copr-dist-git service currently runs)
|
| |
|
|
|
|
| |
upstream
|
| |
|
| |
|
|
|
|
| |
...so that we don't need to chown huge amount of files after deploy
|
|
|
|
| |
...so that the machine can operate meanwhile
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
and a remote copy that changes every run.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
this is needed mainly due rpm2gem which left files behind
See:
https://github.com/fedora-ruby/gem2rpm/issues/85
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
See
https://lists.zx2c4.com/pipermail/cgit/2016-July/003153.html
Lets make cron job, which generate the cgitrc file.
Generate the cgitrc every hours and set TTL to 2 hours.
|
|
|
|
|
|
|
|
|
| |
cgit can take up to 10 minutes - rarely even longer
Once run, it will create cache, but initial run is long.
So I increased timeout a lot.
But to not take down the server with lots of processes, I limited concurent processes.
In normal situation it is more than enough.
And when cgit creates cache, it can lock down few users. But it will create the cache and next run will be fast.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|