ef450d1bce
The 1.20 release is here. Upgrade to this version. Things we change: * Nodejs is updated to v20 to match the alpine 3.18 package version that gitea switched to. * Templates are updated to match upstream 1.20 templates. * We drop the deprecated LFS_CONTENT_PATH from our server config and add an equivalent [lfs] config section. * Normalize app.ini content so that gitea won't write it back out to disk which fails due to permissions (and we don't want it overriding our configs anyway). For this we need to add WORK_PATH, oauth2.JWT_SECRET, and normliazing spacing and quoting for entries. * Set JWT_SIGNING_PRIVATE_KEY_FILE explicitly to be located at /data/gitea/jwt/private.pem otherwise gitea attempts to create the jwt/ directory somewhere it doesn't have permissions to (I think /) and won't be persisted across containers. * Replace log.ENABLE_ACCESS_LOG with log.logger.access.MODE = file as log.ENABLE_ACCESS_LOG is deprecated and doesn't appear to work anymore. This appears to be a documentation issue or they deprecated and removed things more quickly than originaly anticipated. * Add log.ACCESS_LOG_TEMPLATE to readd source port info to the access logs. * Add a templates/custom/header.tmpl file to set theme-color as the config item for this has been removed. The 1.20.0 changelog [0] lists a number of breaking changes. I have tried to capture there here as well as potential impacts to us: * Fix WORK_DIR for docker (root) image (#25738) (#25811) * We set APP_DATA_PATH to /data/gitea in our app.ini config which means we aren't relying on the inferred value from WORK_DIR. I think this isolates us from this chnage. But we can check for any content in /app/gitea on our running containers to be sure. Note we hardcode WORK_PATH to /data/gitea because gitea attempts to write this back to our config file otherwise as a result of this change. * Restrict [actions].DEFAULT_ACTIONS_URL to only github or self (#25581) (#25604) * We disable actions. This shouldn't affect us. * Refactor path & config system (#25330) (#25416) * This is related to the first breaking changes. Basically we need to check our use of WORK_PATH and determine if we need to hardcode it to something. Probably a good idea given how they keep changing this on us... * Fix all possible setting error related storages and added some tests (#23911) (#25244) * We don't use storage configs. This shouldn't affect us. * Use a separate admin page to show global stats, remove actions stat (#25062) * The breaking change only affects the use of Prometheus which we don't have yet. * Remove the service worker (#25010) * Is listed as a breaking change for UI cleanup that we don't need to cleanup. (ui.USE_SERVICE_WORKER can be removed). * Remove meta tags theme-color and default-theme (#24960) * https://github.com/go-gitea/gitea/pull/24960 * Addressed by adding a custome templates/custom/header.tmpl file that sets this meta tag to the existing value. Note this only affects mobile clients so needs to be double checked via a mobile device. * Use [git.config] for reflog cleaning up (#24958) * Affects git.reflog config entries and we don' thave any. * Allow all URL schemes in Markdown links by default (#24805) * TODO determine if we need to limit link types and add that change if so. A point release was made to exclude bad types already. Not sure if there are others we need to add. * Redesign Scoped Access Tokens (#24767) * This breaks scoped tokens with scopes that don't exist anymore. I don't think we use scoped tokens. * Fix team members API endpoint pagination (#24754) * They 1 index the pagination of this endpoint now instead of 0 indexing it. * Rewrite logger system (#24726) * They made changes to the loggers and encourage people to check their logs work as expected when upgrading. Using our test instance logs I don't see anything that is a problem. * Increase default LFS auth timeout from 20m to 24h (#24628) * We don't LFS but can change the timeout if necssary. * Rewrite queue (#24505) * Check for 'Removed queue option:' log entries and clean up corresponding entries in app.ini. We don't have any of these entries in our logs. * Remove unused setting time.FORMAT (#24430) * We didn't have this entry in app.ini. * Refactor setting.Other and remove unused SHOW_FOOTER_BRANDING (#24270) * This setting can be removed from app.ini, but we don't set it. * Correct the access log format (#24085) * We uncorrect it because they removed source port info in the correction step. They did this because some log parsers don't understand having the port info present, but if you are behind a reverse proxy this information is very important. We run gitea behind a reverse proxy. * Reserve ".png" suffix for user/org names (#23992) * .png is no longer a valid user/org name (it didn't work before anyway). * Prefer native parser for SSH public key parsing (#23798) * If you relied on the openssh ssh-keygen executable for public key parsing then you must explicitly set config to use it. I don't think we do as the golang native parser should handle the keytypes we use. * Editor preview support for external renderers (#23333) * This removed an app.ini settings we don't seem to set. * Add Gitea Profile Readmes (#23260) * Readmes in .profile repositories will always be shown now. We don't have .profiles repos so this doesn't affect us. * Refactor ctx in templates (#23105) * This affects custom templates as we may need to replace ctx with ctxData in our templates. * I've searched our templates for 'root', 'ctx', and 'ctxData' and have found no instances. Looking at the files modifying by the commits related to this change:bd7f218dce7c01260e1dwe don't seem to override the affected files. I think we are fine as is. The 1.20.1 changelog indicates there are no breaking changes, and git diff shows no changes to the templates between 1.20.0 and 1.20.1. The 1.20.2 changelog indicates there are no breaking changes, and git diff shows no changes to the templates between 1.20.1 and 1.20.2. The 1.20.3 changelog indicates there is a single breaking change: * Fix the wrong derive path (#26271) (#26318) * If I'm reading the code correctly, I think the problem was storage configuration inheriting the base storage config and particularly the related path. Then when archival storage looked for its config the path was the root gitea storage path and it would inadverdently delete all repos when deleting a single repo or something like that. We don't use these features and these are mirrors anyway so I don't think this really affects us. [0] https://github.com/go-gitea/gitea/blob/v1.20.3/CHANGELOG.md Change-Id: I265f0ad16c0e757a11c1d889996ffe2198625a1a
OpenDev System Configuration
This is the machinery that drives the configuration, testing, continuous integration and deployment of services provided by the OpenDev project.
Services are driven by Ansible playbooks and associated roles stored
here. If you are interested in the configuration of a particular
service, starting at playbooks/service-<name>.yaml
will show you how it is configured.
Most services are deployed via containers; many of them are built or
customised in this repository; see docker/.
A small number of legacy services are still configured with Puppet.
Although the act of running puppet on these hosts is managed by Ansible,
the actual core of their orchestration lives in manifests
and modules.
The files in this repository are provided as an opinionated example service deployment, and to allow the OpenDev Collaboratory to use public software development workflows in order to coordinate changes and improvements to the systems it runs. This repository is not intended as a reconsumable project on its own, and anyone wishing to adjust it to suit their own needs should do so with a fork. The system-config reviewers are unable to evaluate and support use cases for the contents here other than their own.
Testing
OpenDev infrastructure runs a complete testing and continuous-integration environment, powered by Zuul.
Any changes to playbooks, roles or containers will trigger jobs to thoroughly test those changes.
Tests run the orchestration for the modified services on test nodes
assigned to the job. After the testing deployment is configured
(validating the basic environment at least starts running), specific
tests are configured in the testinfra directory to validate
functionality.
Continuous Deployment
Once changes are reviewed and committed, they will be applied
automatically to the production hosts. This is done by Zuul jobs running
in the deploy pipeline. At any one time, you may see these
jobs running live on the status page or
you could check historical runs on the pipeline
results (note there is also an opendev-prod-hourly
pipeline, which ensures things like upstream package updates or
certificate renewals are incorporated in a timely fashion).
Contributing
Contributions are welcome!
You do not need any special permissions to make contributions, even those that will affect production services. Your changes will be automatically tested, reviewed by humans and, once accepted, deployed automatically.
Bug fixes or modifications to existing code are great places to start, and you will see the results of your changes in CI testing. Please remember that this repository consists of configuration and orchestration for OpenDev Collaboratory production systems, so contributions to it will be evaluated on the basis of whether they're useful or applicable to OpenDev's services. Changes intended to make the contents more easily reusable outside OpenDev itself are not in scope, and so will be rejected by reviewers.
You can develop all the playbooks, roles, containers and testing required for a new service just by uploading a change. Using a similar service as a template is generally a good place to start. If deploying to production will require new compute resources (servers, volumes, etc.) these will have to be deployed by an OpenDev administrator before your code is committed. Thus if you know you will need new resources, it is best to coordinate this before review.
The #opendev IRC on OFTC channel is the main place for interactive discussion. Feel free to ask any questions and someone will try to help ASAP. The OpenDev meeting is a co-ordinated time to synchronize on infrastructure issues. Issues should be added to the agenda for discussion; even if you can not attend, you can raise your issue and check back on the logs later. There is also the service-discuss mailing list where you are welcome to send queries or questions.
Documentation
The latest documentation is available at https://docs.opendev.org/opendev/system-config/latest/
That documentation is generated from this repository. You can geneate
it yourself with tox -e docs.