16a4bdce02
There is some correlation that running the manage-projects playbook gives our gitea fits. The bulk of the work done here is in trying to update the descriptions of all projects. There isn't a good way to see if the description is already set first so we just try and ignore errors. This creates potentially thousands of operations all at once and could be why things are sad. We move these operations under the always update flag which is not set on normal runs. If we really need to converge to a good updated state we can manually run the playbook/role with always update set. We also don't set a limit on the number of ThreadPoolExecutor workers which will default to 5 * NumProcs. Could be that tuning this down would make gitea happier. One other thought is that we may not be using request sessions properly for connection reuse. In particular requests notes that you need to set stream to False or read request content to return a connection back to the pool for reuse. We might look into this for further improvements. Change-Id: I6e6fb1eb08303e9da7e38cf493d1871364340000
18 lines
572 B
ReStructuredText
18 lines
572 B
ReStructuredText
Create git repos on a gitea server
|
|
|
|
**Role Variables**
|
|
|
|
.. zuul:rolevar:: gitea_url
|
|
:default: https://localhost:3000
|
|
|
|
The gitea to talk to. This is relative to the remote ansible node which
|
|
means localhost:3000 is on the ansible inventory node.
|
|
|
|
.. zuul:rolevar:: gitea_always_update
|
|
:default: false
|
|
|
|
Whether or not all projects should be coerced to the configured and
|
|
desired state. This defaults to false because it can be expensive to run,
|
|
but if project attributes like issue trackers or descriptions update this
|
|
is used to make those changes.
|