Create and document a better BridgeDB (re)deployment strategy
BridgeDB's current deployment strategy is a little bit crazy.
It would be nice to have automatic deployments, i.e. if a signed git tag of a version number is pushed, and that tag is signed by one of a specific set of keys, it automatically redeploys itself. This might be a tiny bit tricky to set up, and I'm not sure what the opinions of phobos, arma, weasel, et al. are on this.
For the present, I propose the following:
-
Versioning: Using versioneer to automatically create version strings from git tags, and if the current deployment is not directly from a tag, then it automatically creates the version string from the most recent tag + short commit ID.
-
Patch Management: I also propose that some sort of patch management system be used for applying tpo-specific infrastructure changes, like changing the install path, bound IP addrs/ports in the bridgedb.conf file, etc. I've used quilt and it works well; if someone knows of something that is better than quilt for some reason, let me know. Otherwise, I would go with using quilt in a patches/ directory that is a separate git repository.
-
Cleanup: There are a lot of files/directories lying around ponticum.tpo, including, iirc, three copies of bridgedb.git. Some of these files appear to not be used anymore, others I have no idea if they are/were used for deployment, or are used for some metrics tasks, or what.