diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..3b25cb8 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,18 @@ +**Issue #, if available:** n/a + +### Notes + + +### Checklist + +Before you submit a pull request, please make sure you have the following: +- [ ] Code changes are compact and well-structured to facilitate easy review +- [ ] Changes are documented in the README.md and other relevant documentation pages +- [ ] PR title and description accurately reflect the changes and are detailed enough for historical tracking +- [ ] PR contains tests that cover all new code and the code has been manual tested +- [ ] All new dependencies are declared (if any), and no unnecessary libraries are added +- [ ] Performance impacts (if any) of the changes are evaluated and documented +- [ ] Security implications of the changes (if any) are reviewed and addressed +- [ ] I have read the [Contributing Guidelines](../CONTRIBUTING.md) and agree to follow the [Code of Conduct](../CODE_OF_CONDUCT.md) + +By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice. diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml new file mode 100644 index 0000000..df4fa55 --- /dev/null +++ b/.github/workflows/build.yml @@ -0,0 +1,10 @@ +name: build + +on: + pull_request: + branches: ["main"] + +jobs: + tox: + uses: ./.github/workflows/tox.yml + secrets: inherit diff --git a/.github/workflows/documentation-publish.yml b/.github/workflows/docs.yml similarity index 67% rename from .github/workflows/documentation-publish.yml rename to .github/workflows/docs.yml index 7ba7a9c..1ccf900 100644 --- a/.github/workflows/documentation-publish.yml +++ b/.github/workflows/docs.yml @@ -1,4 +1,4 @@ -name: Generate and Publish Documentation for OSML Model Runner Test +name: docs on: workflow_call: @@ -14,18 +14,14 @@ jobs: - uses: actions/setup-python@v5 with: python-version: '3.10' - - name: Install dependencies + - name: Build Docs run: | pip install sphinx python -m pip install sphinx-autoapi python -m pip install sphinx_rtd_theme python -m pip install tox tox-gh-actions - - name: Sphinx build - run: | tox -e docs - - name: Deploy - if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} - uses: peaceiris/actions-gh-pages@v3.9.3 + - uses: peaceiris/actions-gh-pages@v3.9.3 with: publish_branch: gh-pages github_token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/notify-guidance-repo.yml b/.github/workflows/notify.yml similarity index 64% rename from .github/workflows/notify-guidance-repo.yml rename to .github/workflows/notify.yml index 8f3bc47..7e1590c 100644 --- a/.github/workflows/notify-guidance-repo.yml +++ b/.github/workflows/notify.yml @@ -1,18 +1,18 @@ -name: Notify Guidance Overhead Imagery Repo +name: notify on: - workflow_call: + push: + branches: ["main"] jobs: notify: runs-on: ubuntu-latest steps: - - name: Short Sha - uses: benjlevesque/short-sha@v2.2 - - name: Invoke Guidance OSML Submodule Workflow - uses: benc-uk/workflow-dispatch@v1.2.2 + - uses: benjlevesque/short-sha@v2.2 + - uses: benc-uk/workflow-dispatch@v1.2.2 with: repo: aws-solutions-library-samples/guidance-for-overhead-imagery-inference-on-aws workflow: osml_update_submodules.yml + ref: dev token: ${{ secrets.GUIDANCE_OSML_SUBMODULES_ACTION_10_24 }} inputs: '{ "DISPATCH_REPO_NAME" : "${{ github.event.repository.name }}", "DISPATCH_REPO_SHA": "${{ env.SHA }}" }' diff --git a/.github/workflows/osml-model-runner-test-build.yml b/.github/workflows/osml-model-runner-test-build.yml deleted file mode 100644 index 1a5df76..0000000 --- a/.github/workflows/osml-model-runner-test-build.yml +++ /dev/null @@ -1,10 +0,0 @@ -name: "OSML Model Runner Test Build Workflow" - -on: - pull_request: - branches: ["main", "dev"] - -jobs: - Build_Validate_Tox: - uses: ./.github/workflows/python-tox.yml - secrets: inherit diff --git a/.github/workflows/osml-model-runner-test-publish.yml b/.github/workflows/osml-model-runner-test-publish.yml deleted file mode 100644 index 316a169..0000000 --- a/.github/workflows/osml-model-runner-test-publish.yml +++ /dev/null @@ -1,22 +0,0 @@ -name: "OSML Model Runner Test Build and Publish Workflow" - -on: - push: - branches: ["main", "dev"] - -jobs: - Build_Validate_Tox: - uses: ./.github/workflows/python-tox.yml - secrets: inherit - Publish_Python: - needs: [Build_Validate_Tox] - uses: ./.github/workflows/python-publish.yml - secrets: inherit - Publish_Documentation: - needs: [Build_Validate_Tox] - uses: ./.github/workflows/documentation-publish.yml - secrets: inherit - Notify_Guidance_Repo: - needs: [Build_Validate_Tox] - uses: ./.github/workflows/notify-guidance-repo.yml - secrets: inherit diff --git a/.github/workflows/pypi.yml b/.github/workflows/pypi.yml new file mode 100644 index 0000000..03dce9c --- /dev/null +++ b/.github/workflows/pypi.yml @@ -0,0 +1,28 @@ +# This workflow will upload a Python Package using Twine when a release is created +# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#publishing-to-package-registries + +name: pypi + +on: + workflow_call: + +permissions: + contents: read + id-token: write + +jobs: + deploy: + runs-on: ubuntu-latest + environment: + name: release + steps: + - uses: actions/checkout@v4 + - uses: actions/setup-python@v5 + with: + python-version: '3.10' + - name: Build Package + run: | + python -m pip install --upgrade pip + pip install build + python -m build + - uses: pypa/gh-action-pypi-publish@v1.8.11 diff --git a/.github/workflows/python-publish.yml b/.github/workflows/python-publish.yml deleted file mode 100644 index f1e2cfa..0000000 --- a/.github/workflows/python-publish.yml +++ /dev/null @@ -1,33 +0,0 @@ -# This workflow will upload a Python Package using Twine when a release is created -# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#publishing-to-package-registries - -name: Publish Python Package - -on: - workflow_call: - release: - types: [published] - -permissions: - contents: read - id-token: write - -jobs: - deploy: - if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} - runs-on: ubuntu-latest - environment: release - steps: - - uses: actions/checkout@v4 - - name: Set up Python - uses: actions/setup-python@v3 - with: - python-version: '3.x' - - name: Install dependencies - run: | - python -m pip install --upgrade pip - pip install build - - name: Build package - run: python -m build - - name: Publish package - uses: pypa/gh-action-pypi-publish@v1.8.10 diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml new file mode 100644 index 0000000..13843bf --- /dev/null +++ b/.github/workflows/release.yml @@ -0,0 +1,18 @@ +name: release + +on: + release: + types: [published] + +jobs: + tox: + uses: ./.github/workflows/tox.yml + secrets: inherit + pypi: + needs: [tox] + uses: ./.github/workflows/pypi.yml + secrets: inherit + docs: + needs: [pypi] + uses: ./.github/workflows/docs.yml + secrets: inherit diff --git a/.github/workflows/python-tox.yml b/.github/workflows/tox.yml similarity index 57% rename from .github/workflows/python-tox.yml rename to .github/workflows/tox.yml index 00abac0..14d7ff6 100644 --- a/.github/workflows/python-tox.yml +++ b/.github/workflows/tox.yml @@ -1,7 +1,7 @@ # This workflow will install Python dependencies, run tests and lint with a single version of Python # For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python -name: Build/Validation with Tox +name: tox on: workflow_call: @@ -10,21 +10,16 @@ permissions: contents: read jobs: - build: + unit-test: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v4 with: lfs: 'true' - ssh-key: ${{ secrets.git_ssh_key }} - - name: Set up Python 3.10 - uses: actions/setup-python@v3 + - uses: actions/setup-python@v5 with: python-version: "3.10" - - name: Install dependencies + - name: Run Tox run: | python -m pip install --upgrade pip tox - - name: Validate package with tox - run: | - # stop the build if there are Python syntax errors or undefined names tox diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b879f17..0cde532 100755 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,235 +1,190 @@ # OSML Contributing Guidelines Thank you for your interest in contributing to our project! This document will guide you through the process of -contributing to our repository using a release-based GitFlow workflow. Please read the guidelines carefully in order to +contributing to our repository using a Trunk-Based Development workflow. Please read the guidelines carefully to submit your pull requests effectively. ## Table of Contents -- [Release-based GitFlow](#release-based-gitflow) -- [Branches](#branches) +- [Trunk-Based Development](#trunk-based-development) - [Linting](#linting) -- [Use Cases](#use-cases) - - [Develop a new feature](#develop-a-new-feature) - - [Develop multiple features in parallel](#develop-multiple-features-in-parallel) - - [Create and deploy a release](#create-and-deploy-a-release) - - [Production hot fix](#production-hot-fix) - [Code Style](#code-style) - [Commit Messages](#commit-messages) - [Issue Tracking](#issue-tracking) -## Release-based GitFlow +## Trunk-Based Development -We follow a release-based GitFlow branching model to manage our codebase. It involves different types of branches to -ensure proper version control and collaboration. The primary branches in this workflow are: +![Trunk-Based Development](https://github.com/aws-solutions-library-samples/osml-imagery-toolkit/assets/4109909/0b3c03ae-4518-471e-9331-da850f0d2e22) -note- `main`: This branch represents the latest production-ready state of the project code. -- `dev`: This branch is used as the integration branch, combining all feature branches for a specific release. -- `release/vX.Y.Z`: Branches in the format of `release/vX.Y.Z` are used to prepare a specific release. -- `feature/*`: Feature branches are created for the development of new features or significant enhancements. -- `hotfix/*`: Hotfix branches are created for bug fixes against production code. +We follow a trunk-based development model to manage our codebase. +This guide provides a step-by-step example of implementing a Trunk-Based Development (TBD) workflow for development. +The branches developers should create directly off of `main` (our trunk) as part of this workflow are: +- `feature/*`: `feature` branches are created for the development of new features or significant enhancements. -## Branches - -Here's a brief description of the supported branches in our repository: - -![Release Deployment workflow](images/release-deployment.png) - -| Branch | Protected? | Base Branch | Description | -|:-----------------|:-----------|:-------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `main` | YES | N/A | What is live in production (**stable**).
A pull request is required to merge code into `main`. | -| `dev` | YES | `main` | The latest state of development (**unstable**).
A pull request is required to merge code into `dev` | -| `feature/*` | NO | `dev` | Cutting-edge features (**unstable**). These branches are used for any maintenance features / active development. | -| `release/vX.Y.Z` | NO | `dev` | A temporary release branch that follows the [semver](http://semver.org/) versioning. This is what is sent to UAT.
A pull request is required to merge code into any `release/vX.Y.Z` branch. | -| `hotfix/*` | NO | `main` | These are bug fixes against production.
This is used because develop might have moved on from the last published state.
Remember to merge this back into develop and any release branches. | - - -## Linting - -This package uses a number of tools to enforce formatting, linting, and general best practices: -* [eslint](https://github.com/pre-commit/mirrors-eslint) to check pep8 compliance and logical errors in code -* [prettier](https://github.com/pre-commit/mirrors-prettier) to check pep8 compliance and logical errors in code -* [pre-commit](https://github.com/pre-commit/pre-commit-hooks) to install and control linters in githooks - -After pulling the repository, you should enable auto linting git commit hooks by running: +### 1. Creating Feature (Internal Developer) +#### Step 1: Clone the Repository +Clone the repository to your local machine. ```bash -python3 -m pip install pre-commit -pre-commit install +git clone git@github.com:aws-solutions-library-samples/osml-model-runner-test.git ``` -In addition to running the linters against files included in a commit, you can perform linting on all the files -in the package by running: +#### Step 2: Create a New Branch +Create a new branch off `main`, naming it related to the work being done, in this case a feature. ```bash -pre-commit run --all-files --show-diff-on-failure +git checkout -b feature/ ``` -or if using tox -```bash -tox -e lint -```` - -## Use Cases -### Develop a new feature +#### Step 3: Develop and Commit Changes +On the new branch, code, and add commits as necessary. -1. Make sure your `dev` branch is up-to-date - -2. Create a feature branch based off of `dev` - - ```bash - $ git checkout dev - $ git checkout -b feature/new-documentation - $ git push --set-upstream feature/new-documentation - ``` +#### Step 4: Push the New Branch +Push the new branch to trigger unit tests, static code analysis, Sonar cube checks, security checks, etc., +before merging to `main`. +```bash +git push origin feature/ +``` -3. Develop the code for the new feature and commit. Push your changes often. This - allows others to see your changes and suggest improvements/changes as well as - provides a safety net should your hard drive crash. +#### Step 5: Create a Pull Request (PR) +Open a PR against `main` to kick off a discussion. +Open a PR as soon as possible, even if it's not ready (mark it as WIP). +This ensures ample time for review and discussion, improving code quality. - ```bash - $ ... make changes - $ git add -A . - $ git commit -m "Add new documentation files" - $ ... make more changes - $ git add -A . - $ git commit -m "Fix some spelling errors" - $ git push - ``` +#### Step 6: PR Review, Rebase, and Merge +After your PR is reviewed, make any necessary changes by repeating steps 3 and 4. +A team member will merge your PR after approval, +ensuring it's reviewed by someone who has not contributed to the branch. +Also ensure that your branch is rebased against the latest changes to `main`. +```bash +git pull --rebase origin main +git push origin feature/ +``` +Now you are ready to merge your changes! -4. Navigate to the project on [GitHub](https://github.com) and open a pull request with - the following branch settings: - * Base: `dev` - * Compare: `feature/new-documentation` +### 2. Contributing via Fork and Pull Request (External Developer) -5. When the pull request was reviewed, merge and close it and delete the - `feature/new-documentation` branch. +We welcome contributions from the community! +If you're looking to contribute to our project, please follow these steps to fork the repository, +make your changes, and submit a pull request (PR) for review. -### Develop multiple features in parallel +#### Step 1: Fork the Repository -There's nothing special about that. Each developer follows the above [Develop a new feature](#develop-a-new-feature) process. +1. Navigate to the GitHub page of our repository. +2. In the top-right corner of the page, click the **Fork** button. This creates a copy of the repository in your GitHub account. -### Create and deploy a release -1. Merge `main` into `dev` to ensure the new release will contain the - latest production code. This reduces the chance of a merge conflict during - the release. +#### Step 2: Clone Your Fork +1. On your GitHub page for the forked repository, click the **Clone** or **Download** button and copy the URL. +2. Open your terminal or command prompt. +3. Clone your fork using the command: ```bash - $ git checkout dev - $ git merge main + git clone [URL of the forked repository] ``` - -2. Create a new `release/vX.Y.Z` release branch off of `dev`. - +4. Navigate into the cloned repository: ```bash - $ git checkout -b release/vX.Y.Z - $ git push --set-upstream release/vX.Y.Z + cd [repository-name] ``` -3. Stabilize the release by using bugfix branches off of the `release/vX.Y.Z` branch - (the same way you would do a feature branch off of `dev`). +#### Step 3: Create a New Branch +Create a new branch for your changes based off the latest `main`: ```bash - $ git checkout release/vX.Y.Z - $ git checkout -b hotfix/fix-label-alignment - $ git push --set-upstream hotfix/fix-label-alignment - ... do work - $ git commit -m "Adjust label to align with button" - $ git push + git checkout -b [branch-name] ``` +Follow the branch naming conventions mentioned earlier. -4. When the code is ready to release, navigate to the project on - [GitHub](https://github.com) and open a pull request with the following branch - settings: - * Base: `main` - * Compare: `release/vX.Y.Z` - Paste the Release Checklist into the PR body. Each project should define a release - checklist. TBD - will link release checklist here. - -5. At some point in the checklist you will merge the release branch into `main`. - You can do this by using the "Merge pull request" button on the release PR. - -6. Now you are ready to create the actual release. Navigate to the project page - on GitHub and draft a new release with the following settings: - * Tag version: `vX.Y.Z` - * Target: `main` - * Release title: `Release vX.Y.Z` - * Description: Includes a high-level list of things changed in this release. - Click `Publish release`. +If you wish to work with a stable release version of our project, +you might want to clone a specific release tag rather than the latest state of the main branch. +Here's how you can do that: -7. Merge the `release/vX.Y.Z` into `dev`. - - ```bash - $ git checkout dev - $ git merge release/vX.Y.Z - $ git push - ``` +1. **List Available Tags**: First, to see the available tags (release versions), navigate to the repository on GitHub, then go to the **Tags** section in the **Releases** tab. Alternatively, you can list tags from the command line using: + ```bash + git ls-remote --tags [URL of the original repository] + ``` +2. **Clone the Repository**: If you haven't already, clone the repository using: + ```bash + git clone [URL of the original repository] + ``` +3. **Checkout the Tag**: Navigate into the cloned repository directory: + ```bash + cd [repository-name] + ``` + Then, checkout the specific tag you're interested in working with: + ```bash + git checkout tags/[tag-name] + ``` + Replace `[tag-name]` with the desired tag. + This will put you in a 'detached HEAD' state, which is fine for browsing a tag. -8. Finish off the tasks in the release checklist. Once everything is done, close - the release PR. +If you plan to make changes starting from this tag and contribute back, +it's a good idea to create a new branch from this tag: -9. Delete the release branch on GitHub. +```bash +git checkout -b [new-branch-name] tags/[tag-name] +``` -### Production hot fix +This way, you can start your changes from a specific version of the project. -A production hotfix is very similar to a full-scale release except that you do -your work in a branch taken directly off of `main`. Hotfixes are useful in cases -where you want to patch a bug in a released version, but `dev` has unreleased -code in it already. +#### Step 4: Make Your Changes -**TBD: Insert diagram** +- Make the necessary changes in your branch. Feel free to add, edit, or remove content as needed. -1. Create a hot fix branch based off of `main`. +#### Step 5: Commit Your Changes +1. Stage your changes for commit: ```bash - $ git checkout main - $ git checkout -b hotfix/documentation-broken-links - $ git push --set-upstream origin hotfix/documentation-broken-links + git add . + ``` +2. Commit your changes with a meaningful commit message: + ```bash + git commit -m "A descriptive message explaining your changes" ``` -2. Add a test case to validate the bug, fix the bug, and commit. +#### Step 6: Push Your Changes +1. Push your changes to your fork: ```bash - ... add test, fix bug, verify - $ git add -A . - $ git commit -m "Fix broken links" - $ git push + git push origin [branch-name] ``` -3. Navigate to the project on [GitHub](https://github.com) and open a pull request - with the following branch settings: - * Base: `main` - * Compare: `hotfix/documentation-broken-links` - Paste your release checklist into the PR and work through the PR to get the - hotfix into production. +#### Step 7: Create a Pull Request -4. At some point in the checklist you will merge the hotfix branch into `main`. - You can do this by using the "Merge pull request" button on the release PR. +1. Navigate to your forked repository on GitHub. +2. Click the **Pull Request** button. +3. Ensure the base repository is the original repository you forked from and the base branch is the one you want your changes pulled into. +4. Select your branch as the compare branch. +5. Fill in a title and description for your pull request explaining the changes you've made. +6. Click **Create Pull Request**. -5. Now that the hotfix code is in `main` you are ready to create the actual - release. Navigate to the project page on GitHub and draft a new release with - the following settings: - * Tag version: `vX.Y.Z` - * Target: `main` - * Release title: `Release vX.Y.Z (hotfix)` - * Description: Includes a high-level list of things changed in this release. +#### Final Step: Await Review -Click `Publish release`. +- Once your pull request is submitted, our team will review your changes. We may request further modifications or provide feedback before merging your changes. +- Keep an eye on your GitHub notifications for comments or requests for changes from the project maintainers. -*Note: Hotfix releases _are_ actual releases. You should bump at least the -patch part of the version when releasing a hotfix, and so even hotfixes go -through the process of creating a release like this.* +## Linting -1. Merge the `hotfix/documentation-broken-links` into `dev`. +This package uses a number of tools to enforce formatting, linting, and general best practices: +* [eslint](https://github.com/pre-commit/mirrors-eslint) to check pep8 compliance and logical errors in code +* [prettier](https://github.com/pre-commit/mirrors-prettier) to check pep8 compliance and logical errors in code +* [pre-commit](https://github.com/pre-commit/pre-commit-hooks) to install and control linters in githooks - ```bash - $ git checkout dev - $ git merge hotfix/documentation-broken-links - $ git push - ``` +After pulling the repository, you should enable auto linting git commit hooks by running: -2. Finish off the tasks in the release checklist. Once everything is done, close - the hotfix PR. +```bash +python3 -m pip install pre-commit +pre-commit install +``` + +In addition to running the linters against files included in a commit, you can perform linting on all the files +in the package by running: +```bash +pre-commit run --all-files --show-diff-on-failure +``` +or if using tox +```bash +tox -e lint +```` ## Code Style @@ -253,7 +208,7 @@ documentation for examples and additional context. ## Issue Tracking -We utilize the issue tracking functionality of GitHub to manage our project's roadmap and track bugs or feature requests. +We use the issue tracking functionality of GitHub to manage our project's roadmap and track bugs or feature requests. If you encounter any problems or have a new idea, please search the issues to ensure it hasn't already been reported. If necessary, open a new issue providing a clear description, steps to reproduce, and any relevant information. diff --git a/README.md b/README.md index ed8e5b8..c704721 100755 --- a/README.md +++ b/README.md @@ -20,8 +20,7 @@ This package contains the integration tests for OSML application First, ensure you have installed the following tools locally 1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) -2. [docker](https://nodejs.org/en) -3. [tox](https://tox.wiki/en/latest/installation.html) +2. [tox](https://tox.wiki/en/latest/installation.html) ### Installation Guide @@ -47,18 +46,23 @@ version of the API documents. tox -e docs ``` -### Build and Local Testing +### Local Testing + + +#### Credentials + +Credentials from the user's account are volume mounted into the container's root directory. + +**Processing an image:** You can run the integration tests against your dev account by exporting the required parameters and using the pytest CLI by -using the python script ``bin/process_image.py``. Do not forget to load up your AWS credentials into your terminal, please follow this [guide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) on how to load your aws credentials. +using the python script ``bin/process_image.py``. Remember to load up your AWS credentials into your terminal, please follow this [guide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) on how to load your aws credentials. ``` python bin/process_image.py --image --model ``` -For list of - **Examples:** ``` @@ -78,19 +82,19 @@ python3 bin/process_image.py --help To execute the integration test, exclude `--skip_integ` from the command line interface. It is essential that the images and models listed in the table below are aligned accurately for the test to succeed. Conversely, by adding `--skip_integ` to the CLI, all comparison checks will be bypassed, rendering the table irrelevant for testing purposes. -| image | model | -| -- | -- | -| small | centerpoint | -| meta | centerpoint | -| sicd_capella_chip_ntf | centerpoint | -| sicd_umbra_chip_ntf | centerpoint | +| image | model | +|-----------------------------|-------------| +| small | centerpoint | +| meta | centerpoint | +| sicd_capella_chip_ntf | centerpoint | +| sicd_umbra_chip_ntf | centerpoint | | sicd_interferometric_hh_ntf | centerpoint | -| wbid | centerpoint | -| large | flood | -| tile_tif | aircraft | -| tile_ntf | aircraft | -| tile_jpeg | aircraft | -| tile_png | aircraft | +| wbid | centerpoint | +| large | flood | +| tile_tif | aircraft | +| tile_ntf | aircraft | +| tile_jpeg | aircraft | +| tile_png | aircraft | ### Running LoadTest diff --git a/images/release-deployment.png b/images/release-deployment.png deleted file mode 100644 index 65dcc2b..0000000 Binary files a/images/release-deployment.png and /dev/null differ diff --git a/images/release_deployment.sketch b/images/release_deployment.sketch deleted file mode 100644 index 1d43e59..0000000 Binary files a/images/release_deployment.sketch and /dev/null differ