[Task]: Backend Repo Setup

[widal001]

Summary

Set up the backend portion of the repository with the language decided in #38 and the set of code quality tools selected in #101

User Stories

• As an open source contributor, I want to:
  • be able to reference documentation explaining how to use the developer tools, so that I don't have to learn how to use these tools on my own in order to contribute to the project
  • have full test coverage for the codebase, so that I know when I've introduce code that changes or breaks existing behavior
  • have code formatting and standards enforced with automated tooling, so that I don't have to learn and check that my code adheres to those standards manually
• As a maintainer of the project, I want to:
  • have code quality checks run automatically on each push, so that formatting, linting, or security issues are caught before being deployed to production
  • ensure that new contributions meet certain thresholds for test coverage, so that code contributions from internal and external developers also include tests which validate the code's behavior

Acceptance Criteria

• [x] An api/ sub-directory has been created with a README that includes instructions for how to install and run the code in this sub-directory
• [x] At least 2 dependencies have been added to the project, and the dependency manager selected in #101 automatically checks for dependency conflicts and offers suggestions for how to reconcile those conflicts:
• [x] A dummy test has been created (i.e. assert True) that users can execute to verify they've installed the project correctly
• [x] The following checks are run before every commit are possible:
  • [x] Auto-formatting
  • [x] Linting (basic)
  • [x] Type checks (optional)
  • [ ] Commit formatting (preferably conventional commit)
• [x] The following checks are run with each push to the remote GitHub repo, and these checks are run against all minor versions of the backend language we plan to support:
  • [x] Auto-formatting
  • [x] Linting (complete)
  • [x] Type checks
  • [ ] Dependency vulnerability checks
  • [ ] Open source license checks
  • [x] Unit tests
  • [x] Test coverage
• [ ] A PR is blocked from merging if any of the checks above fail
• [ ] At least 2 people who did not contribute to this PR have installed and run the dummy test locally

Proposed Testing Strategy

1. Unit tests: Create a test_sample test that simply asserts True or asserts the version number
2. Manual Tests: Someone who did not contribute to the PR checks out the PR locally, follows the instructions in the README to install the code, run the tests and the code quality checks locally, and all checks/tests pass.

[acouch]

We have the opportunity to utilize a Flask template focused on federal level clients. Some of the features and benefits of this template is:

• Python/Flask-based API that writes to a database using API key authentication with example /health endpoints
• PostgreSQL database + Alembic migrations configured for updating the database when the SQLAlchemy database models are updated
• Thorough formatting & linting tools
• Logging, with formatting in both human-readable and JSON formats
• Docker support
• Ability to run the various utility scripts inside or outside of Docker
• Easy environment variable configuration for local development using a local.env file
• Testing
• A Makefile with testing, deployment, building, database migration, and other commands
• Excellent documentation

Steps

Some steps to implement this, given the user stories and acceptance criteria above, include:

• [x] Create an api directory and follow the install steps
• [x] Add github workflows and rename ci-app.yml to ci-api.yml
• [x] Add README.md to api folder that includes (Title, local development, testing and other relevant info), linking to docs
• [x] Update api/openapi.generated.yml to include proper Grants Equity info
• [x] Update api/pyproject.toml to include proper Grants Equity info
• [x] Update api/src/app.py to include proper Grants Equity info
• [x] Decide if we want to keep "docs" in the api folder or move to the root documentation
• [x] Decide if we want to adopt the existing ADRs
• [ ] Remove v1/users endpoints, as we don't have that endpoint identified
• [x] Review documentation is cohesive

[daphnegold]

Breaking off pre-commit hooks into a separate issue. There's a lot going on in here and the current tool configured in the repo won't suit our needs. Might break off other things. @widal001 are you okay with whoever picks up the pre-commit hook issue making an executive decision around what tool to use, or do we want an ADR?

Ideas: Github Actions locally, Make something or other, Husky, can pre-commit be configured with custom commands?

EDIT: I was totally off, on further inspection of the documentation of pre-commit, it allows for creation of custom hooks in multiple languages. Modified the issue to configure the pre-commit hook because it's still just a nice to have.

223

[daphnegold]

Regarding security decisions made in the back-end tooling ADR, we decided to use a package called Safety for vulnerability checks. After doing the front-end tooling ADR, a tool called Renovate was suggested there. Renovate also supports Python. I'm going to hold off on installing Safety for now, because I think for consistency it might be preferable to use Renovate bot in the back-end as well? Thoughts? Can always go in and edit the ADR.

If we only want to run Renovate for vulnerability/security updates: https://github.com/renovatebot/renovate/discussions/15490

EDIT: Offline discussed with @widal001 to also include Safety and then we can figure out if we need it later because it's not adding any value.

Will be configured as quick follow: #239

[daphnegold]

A PR is blocked from merging if any of the checks above fail

I will need adult supervision (Github admin) for this and it will have to be a post-merge follow up. As far as I'm aware this is a setting in Github. :D

[daphnegold]

Commit formatting (preferably conventional commit)

The dev team is meeting to discuss how we would like to handle commits, so this can be a fast follow.

[daphnegold]

Configure license checks pulled into a separate task. Need to make sure that the chosen package pip-licenses will allow us to fail automated checks or if we need another package.

238

[daphnegold]

Remove v1/users endpoints, as we don't have that endpoint identified

Decided to leave these as reference and a starting point to modify to build our new endpoints since team is learning Python and Flask.