I am living 'oh that a man's reach should exceed his grasp' and I'd like to log my 'heaven', but just for Python web applications and documentation.
I've used cookiecutter-django to begin a practice project and to avoid the main problem I was going to solve, I've been thinking about how best to track the project, without using Jira or web services from elsewhere. I acknowledge the lesson of 'xkcd's "there are thirteen competing standards, we should have one to unify them -> there are fourteen competing standards" but I decline it.
I've been trying to get a CI/CD setup going and the amount of special tooling that I don't normally use seems crazy. Here is an alternate concept that creates a lot of work but keeps all of it as far left as possible - the developers repositories. This is at least partly inspired by this talk from Simon Willison.
Idea 1. Test reports are output to a tracked folder and can be identified with the git commit snapshot they ran on. They are always added to the repository (e.g. by pre-commit) whenever a threshold is met, e.g. at least when merging to the default branch.
The idea would be to smooth all merging to downstream repositories. If a repository has new commits, it is ahead, and if its tests are all passing its worth trialling a merge. If the merge candidate passes all tests, the new state can be committed; if the merge should be aborted. This will work in a lot of settings, but there are some risks* too.
Idea 2. Issue tracking, changelogs, release notes bugs, wikis and other things are just documentation and can live in a subfolder of your documentation. Using the 'sphinx' documentation system, you already build the documentation for the project along with the project - the idea is to extend that with files for issues that are composed in the repo.
Some cool things you could probably implement with a little code in conf.py (which, given the state of the world, probably means 'someone somewhere is doing this and wondering why they can't get more github stars'):
- show from git log the commits, merges, open branches with links from summaries into more detail (e.g. -p to get patch summaries)
- show the current lists of issues, bugs, etc, using the toctree or other directives.
- show test results for each commit
If you want to be legends, you can further reorganize that into a single table integrate the branch names and the issues.
Idea 3. Use playwright's ability to produce animated gifs of the latest look in the documentation; that will look killer. Update these at pre-commit.
*risks: in a large project you will probably have some special resources that are not perfectly replicated in your development environment. For example, your production database will have a certain schema and you will need to update that schema in order to use the updated code. While its easy to to revert the code, and its possible to reverse the schema migrations, the migrations may have destroyed data that then also needs to be recovered. Other setup, like certificates or connections could be destroyed. Although leaving folders for local settings or migrations untracked seems like it would help, things like data migrations need to know their place in the migration history graph. A git merge strategy setting will still allow additional migration files to be merged into the folders. Unless you're postgres or sqlite, you don't have enough test coverage to be perfectly confident that what worked 'there' will work 'here.'
