==============================
Automated reporting for FFRD HEC-RAS models
This README provides crucial information for setting up and contributing to the auto_report project. It covers essential topics such as the dev-container setup, Python APIs, CLIs, authentication, running tests, linting, CI/CD, and formatting guidelines. If you haven't already, please read this document in it's entirety. It is necessary to ensure a smooth development process and maintain consistency across the project. If you do not understand something, reach out to someone who does!
Review the following best practices for information on how to get your code merged! All code should follow the coding standards in the Coding Standards. Please also review the GitHub and Version Control wiki page. Please set up branch protection rules to enforce pull request reviews prior to merging into protected branches (especially if CI/CD is configured to run on some branches). If you require a staging branch, it may be helpful to set it as the default branch so pull request target that branch by default.
Be sure your code is formatted with
black
and all linting and pytest checks pass before requesting a review of your code (see Formatting Linting and Testing below)
Before you can start developing, please make sure you have the following software installed on your machine:
Ctrl+Shift+P
or Cmd+Shift+P
) and select "Dev Containers: Rebuild and Reopen in Container".Use the env.yaml
file at the project root directory to keep pinned dependencies up-to-date and version controlled.
Only include top level dependencies in this file (i.e. only packages you explicity want installed and use in your code) and Only inlcude the major.minor version (this allows all patches to automatically be applied when the project is rebuilt)
If your dependencies are more complex (i.e cannot be installed / managed with micromamba alone) you may need to update the .devcontainer/Dockerfile
and apply similar modification to the production Dockerfile
.
This repository contains the source code for the various tools available through the auto_report
package, cli, and Boathouse toolkit. This repository provides a Python API, CLI, and Boathouse interface to each tool.
The Python API is accessed through the auto_report
Python package. You will find the following in the src/
folder related to the Python API:
auto_report
Python package
In order to run the tools or tests, you must be authenticated with an AWS profile that has access to develop on this repository. You can request access keys from a project developer (preferred), or sign in on the CLI with your AWS SSO credentials for the DAA AWS account.
If you are not authenticated, all tools and tests will fail to run and report Unauthorized to standard output.
If using project keys for authentication. Make a new file .env
file in the root of the project directory (this file should not be commited to source control and is ignored in the .gitignore
). Copy the format of the variables present in the .env.template
file and fill in the necessary keys.
This project uses black
as the Python formatter. Before you merge your code into staging or main, you should make sure all your code is formatted by running the following command from the root of the project.
black .
This project includes a linter for Python called pylint
. Your source code will be linted in the editor. To run the linter manually, run the following command from the root directory
pylint --fail-under=9 src*
To run the project tests, open a python file and click the tests button on the extensions panel of VSCode. You may need to configure the tests with the GUI. To do this, select Configure Tests and choose pytest as the testing framework and tests
as the testing directory.
Once the tests are loaded, you can run them with the play button in the tests extension.
Alternatively, you can run the following command from the root directory to run all tests
pytest
Normally, it is best to make a testing file under the tests
folder to test functionality, but it is occasionally helpful to be able to run the scripts directly. In this case, you can change directories to the src/
directory which will allow you to import files from the package or run standalone scripts that import files from the package:
cd src
python <- will open a python shell where "import my_package" will work
OR
cd src
python myscript.py <- the script can import code from my_package
To test this image in Boathouse without pushing to staging or production branches, you can build it locally on Windows using the build-dev-image.ps1 script. First, you may need to set the execution policy
In powershell:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
.\build-dev-image.ps1
This will create a local docker image for auto_report tagged dev
that will be available in Boathouse.
βββ LICENSE
βββ README.md <- The top-level README for developers using this project.
βββ .devcontainer
βΒ Β βββ devcontainer.json <- Dev Container specifications
βΒ Β βββ Dockerfile <- Container definition for dev environment
βΒ Β βββ README.md <- Documentation for devcontainer
β
βββ .github
βΒ Β βββ workflows
βΒ Β βββ build_and_push_production.yml <- CI/CD instructions for merges into main branch (copy from another repo)
β βββ build_and_push_staging.yml <- CI/CD instructions for merges into staging branch (copy from another repo)
| βββ lint_and_test.yml <- CI/CD instructions to lint and test code on PR
β
βββ data
βΒ Β βββ 0_source <- Source data, minimally altered from source
βΒ Β βββ 1_interim <- Intermediate data that has been transformed.
βΒ Β βββ 2_production <- Fully transformed, clean datasets for next steps
β
βββ models <- Trained and serialized models, model predictions, or model summaries
β
βββ notebooks <- Jupyter notebooks. Naming convention is a number (for ordering),
β the creator's initials, and a short `-` delimited description, e.g.
β `1.0-jqp-initial-data-exploration`.
β
βββ env.yml <- The requirements file for reproducing the analysis environment
β
βββ src
βΒ Β βββ *repo_name <- Python source code for use in this project.
β β βββ __init__.py <- Package indicator, various uses
β β βββ authorizer.py <- Boathouse utility to perform user authentication
β β βββ sp00_python_template.py <- Example of how to structure functional programming scripts
β β βββ sp01_python_runner_template.py <- Example of how to store project specific parameters
β β
βΒ Β βββ *cli.py <- The command line interface definition that is called by Boathouse
β
βββ test
βΒ Β βββ __init__.py <- Package indicator, various uses
βΒ Β βββ test_python_template.py <- Example of how to test functions in src folder
β
βββ .gitattributes <- Handles consistent line endings in source control across multiple operating systems
β
βββ .gitignore <- Handles which directories to keep out of version control
β
βββ .dockerignore <- Which files to ignore when building docker image for production
β
βββ .gitconfig <- Handles consistent file permissions in source control across multiple operating systems
β
βββ .pylintrc <- Customizations to pylint default settings
β
βββ pytest.ini <- Customizations to pytest
β
βββ Dockerfile <- The production Dockerfile used for Boathouse tools
β
βββ interface.json <- Defines the Boathouse GUI for each tool
β
βββ LICENSE <- MBI license (copyright to MBI)
β
βββ README.md <- Template information
|
βββ .env.template <- Template env file (used to create a new .env file with your environment variables for authentication)
|
βββ build-dev-image.ps1 <- Build a dev image for Boathouse Staging / Dev local testing
β
βββ tox.ini <- Alternative method to store project parameters (currently not used)
Project based on the cookiecutter data science project template. #cookiecutterdatascience