Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Welcome puritan. Where version control is concerned we treat sorcery like the inhabitants of Salem. Only repositories with the upmost level of seriousness, transparency and rigor are allowed.

Creating a Repository

Not rocket science but bear in mind the following checklist:

  • By default Github makes the person who has created the repository the admin. However it is better to set the systems team (or in the future groups within systems) as admin.

  • Ensure file contains the registry .gitignore template.

  • Consider if repo should be open source.

  • Add static testing with tox as a minimum but unit tests should be included whenever possible. As a general rule this is just a case of copy pasting a tox.ini file from elsewhere.

    • Code formatting - Black, ruff

    • Linter/Typechecker - mypy, pyright as appropriate

    • Security - bandit

    • Unit testing - pytest

  • Enable registry ssh secret. This is required for github actions to use any of the private repos.

  • If it’s a package consider publishing it to pypi, if it’s a service consider dockerising it.

  • We use python poetry as standard for python dependency management

Updating a Repository

Commits should, as much as possible, contain changes that relate to a specific feature or ticket. This is to allow them to be reversed later if needed. The branch should be named after the Jira ticket or Epic where ever possible.

The commit message should describe what has changed. If the change relates to a JIRA ticket it should be prefixed with the ticket identifier.

git commit -m "RR-123 I changed function val_banana to add a check for apples"

commit messages should clearly describe changes and the version of the repository should be amended accordingly.

Maintaining a Repository

Useful reference Articles/Sites

  • No labels