Authors: Ted Liefeld, Jens Luebeck, Edwin Huang, Forrest Kim, Thorin Tabor, Michael Chan, Dhruv Khatri, Kyra Fetter, Gino Prasad, Rohil Ahuja, Rishaan Kenkre, Tushar Agashe, Devika Torvi, Madalina Giurgiu, Vineet Bafna
This is the main repository for the AmpliconRepository website. The documentation below provides intsructions on deploying the site locally, for development purposes.
- How to install the development environment for AmpliconRepository
- How to set up your development environment using docker compose
- Testing datasets
- Pushing changes to GitHub and merging PRs
- Using the development server
- Logging in as admin
- Running the automated tests
- REST API v1
- How to deploy and update the production server for AmpliconRepository
Option A: Manually install modules and configure the environment step-by-step.
Option B: Use Docker to deploy the server and its environment on your system.
- Python Virtual Environment (3.8 or higher)
- Clone repo using https, ssh, or GitHub Desktop to your local machine
- In a terminal window, move to the cloned GitHub repo
- Go to the AmpliconRepository top level directory (should see
requirements.txt)
- Create a new Python virtual environment:
python -m venv ampliconenv
- Activate the new environment (you need to do this everytime before running the server):
source ampliconenv/bin/activate
- Install required packages
pip install -r requirements.txt
- Create a new Conda environment
conda create -n ampliconenv "python>=3.8,<3.13"
- To activate
conda activate ampliconenv
- Install pip to that environment
conda install pip -n ampliconenv
- Install required packages
~/[anaconda3/miniconda3]/envs/ampliconenv/bin/pip install -r requirements.txt
- Install MongoDB
-
In Ubuntu this can be done with
sudo apt install mongodb-server-core- For newer versions of Ubuntu (e.g. 22.04+), follow the instructions here: https://www.fosstechnix.com/how-to-install-mongodb-on-ubuntu-22-04-lts/
-
In macOS this can be done with
git config --global init.defaultBranch mainbrew tap mongodb/brewbrew install mongodb-community@6.0 -
If the package is not found you may need to follow the directions here.
-
- If you don't have a database location set up, set up a location:
mkdir -p ~/data/db/
- In a terminal window or tab with the
ampliconenvenvironment active, run MongoDB locally:
mongod --dbpath ~/data/dbormongod --dbpath <DB_PATH>
- Download MongoDB Compass: https://www.mongodb.com/docs/compass/current/install/#download-and-install-compass
- Open the MongoDB Compass app after starting MongoDB locally
- Connect to your local instance of MongoDB:
URI:
mongodb://localhost:27017
- Relevant data will be located in
/AmpliconRepository/projects/ - You can periodically clear your local deployment mongodb files using Compass so that your disk does not fill up.
- Run
export DB_URI_SECRET='mongodb://localhost:27017'in your terminal to set the environment variable for your local database.- So that this is active every time, you can add the command above to your
~/.bashrcfile
- So that this is active every time, you can add the command above to your
- Note that the latest version of Compass (1.34.2) won't work with our older DB version. You can get an old compass for mac at https://downloads.mongodb.com/compass/mongodb-compass-1.28.4-darwin-x64.dmg
Periodically, local development uploads and test projects can make MongoDB's GridFS storage very large. Start with read-only reports:
source caper/config.sh && python purge-local-db.py --gridfs-usage-by-type --limit 25
source caper/config.sh && python purge-local-db.py --gridfs-usage-by-project --limit 25
source caper/config.sh && python purge-local-db.py --tarfile-report --limit 25
The recommended cleanup is two-stage. First remove unreachable project documents and the GridFS/S3/tmp files attached to those documents:
source caper/config.sh && cd caper && python ../cleanup_orphaned_projects.py --dry-run
source caper/config.sh && cd caper && python ../cleanup_orphaned_projects.py
Then remove remaining GridFS blobs that are not referenced by reachable project documents:
source caper/config.sh && python purge-local-db.py --smart-gridfs
source caper/config.sh && python purge-local-db.py --smart-gridfs --execute
purge-local-db.py is dry-run by default; destructive actions require
--execute. A full local project/GridFS wipe is still available, but must be
requested explicitly:
source caper/config.sh && python purge-local-db.py --all-project-data --execute
MongoDB/WiredTiger may reuse freed space internally instead of immediately
shrinking ~/data/db. To return space to the OS after a large cleanup, use a
compact/repair operation or dump and restore the local database into a fresh
dbpath.
the easiest way... edit the path at the end to the local drive you want it to use
docker run -d --name neo4j -p 7474:7474 -p 7687:7687 --env NEO4J_AUTH=neo4j/$NEO4J_PASSWORD_SECRET -v /home/ubuntu/AmpliconRepository-dev/neo4j neo4j
Download and unzip the tar file:
curl -O -C - http://dist.neo4j.org/neo4j-community-5.12.0-unix.tar.gz
tar -xvzf neo4j-community-5.12.0-unix.tar.gz
Start neo4j with the console command:
cd neo4j-community-5.12.0
bin/neo4j console
Go to http://localhost:7474/browser/ and change the auth settings. By default, both user and password are 'neo4j'. Keep user as 'neo4j' and change password to 'password'.
The environment is now set up. Ensure that neo4j is running before querying the graph.
Alternatively, go to https://neo4j.com/deployment-center/, then download the rpm file for the latest Community Edition under the section titled 'Graph Database Self-Managed'. Further instructions are available upon clicking Download. Note that this method has not been tested by our team.
Please follow this documentation to set up the latest version of Neo4j Community Edition
In brief, you can do
wget -O - https://debian.neo4j.com/neotechnology.gpg.key | sudo apt-key add -
echo 'deb https://debian.neo4j.com stable latest' | sudo tee /etc/apt/sources.list.d/neo4j.list
sudo apt-get update
sudo apt-get install neo4j
Register for an account at Neo4j Aura Console
Then launch it by running
sudo neo4j start
Visit http://localhost:7474 and login with neo4j as both the user and password. You will be prompted to set a password for future use.
You must set the updated password to the value in your config.sh file (value of NEO4J_PASSWORD_SECRET)
For shutdown at the end of your session, you can do sudo neo4j stop
- Make sure you have the
config.shfile from another developer (this contains secret key information) - Run the command to initialize variables (from the top-level repo directory):
source caper/config.sh
For local deployments, you will need to ensure that the following two variables are set to FALSE, as shown below
export S3_STATIC_FILES=FALSE
export S3_FILE_DOWNLOADS='FALSE'
IMPORTANT: After recieving your config.sh, please ensure you do not upload it to Github or make it available publicly anywhere.
- Open a terminal window or tab with the
ampliconenvenvironment active - Move to the
caper/folder (should seemanage.py) - Run the server locally:
python manage.py runserver
- Open the application on a web browser (recommend using a private/incognito window for faster development):
- Troublshooting tip: If you face an error that says port 8000 is already in use, you can kill all tasks using that port by doing
sudo fuser -k 8000/tcp
These steps guide users on how to set up their development environment using Docker and docker compose as an alternative to python or conda-based package management and installation. This is the simplest way to locally deploy the server for new users.
Important: You first need to install docker>=20.10 on your machine.
To test the installation of Docker please do:
# check version: e.g. Docker version 20.10.8, build 3967b7d
docker --version
# check if compose module is present
docker compose --help
# check docker engine installation
sudo docker run hello-worldBuild and run your development webserver and mongo db using docker:
cd AmpliconRepository
# place config.sh in caper/, and place .env in current dir
# change UID and GID in .env to match the host configuration
# create all folders which you want to expose to the container
mkdir -p logs tmp .aws .git
docker compose -f docker-compose-dev.yml build --no-cache --progress=plain
docker compose -f docker-compose-dev.yml up -d
# then visit http://localhost:8000/ in your web browser
# once finished, to shutdown:
docker compose -f docker-compose-dev.yml downi. Start your docker daemon and make sure is running:
# for linux
sudo systemctl start docker
docker --help
docker compose --help
# or alternatively start manually from interface (macos or windows)git clone https://github.com/AmpliconSuite/AmpliconRepository.gitThis command will create a Docker image genepattern/amplicon-repo:dev-test with your environment, all dependencies and application code you need to run the webserver.
Additionally, this command will pull a mongo:4 image for the test database.
First, obtain the secret files .env and config.sh from another developer. Do not share these files with others outside the project. Do not upload them anywhere. Keep them private.
Next, Place .env under AmpliconRepository/ and config.sh under AmpliconRepository/caper/.
You should see these required files:
docker-compose-dev.ymlDockerfile.envrequirements.txtcaper/config.sh
cd AmpliconRepository
docker compose -f docker-compose-dev.yml build --progress=plain --no-cacheThis command will:
- create two containers, one for the webserver (
amplicon-dev) and one for the mongo database (ampliconrepository_mongodb_1) - will use
.envto configure all environment variables used by the webserver and mongodb - will start the webserver on
localhost:8000 - will start a mongodb instance listening on port
27017 - will mount a volume with your source code
-v ${PWD}:/srv/:rw
# create all folders exposed to container
mkdir -p logs tmp .aws .git
# start container using the host UID and GID (change in .env)
docker compose -f docker-compose-dev.yml up -d
#[+] Running 2/2
# ⠿ Container ampliconrepository-mongodb-1 Started 0.3s
# ⠿ Container amplicon-dev Started 1.1sTo check if your containers are running do:
docker psand you should see something like below:
# CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
# 311a560ec20a genepattern/amplicon-repo:dev "/bin/sh -c 'echo \"H…" 3 minutes ago Up About a minute 0.0.0.0:8000->8000/tcp amplicon-dev
# deaa521621f1 mongo:4 "docker-entrypoint.s…" 4 days ago Up About a minute 0.0.0.0:27017->27017/tcp ampliconrepository_mongodb_1
To view the site locally, visit http://localhost:8000/ in your web browser.
To stop the webserver and mongodb service:
docker compose -f docker-compose-dev.yml down
#[+] Running 3/2
# ⠿ Container amplicon-dev Removed 10.3s
# ⠿ Container ampliconrepository-mongodb-1 Removed 0.3s
# ⠿ Network ampliconrepository_default Removed 0.0sBefore you build your image you can check if the config.sh is set correctly by doing:
docker compose -f docker-compose-dev.yml configThis command will show you the docker-compose-dev.yml customized with your environment variables.
You can check the environment variables which your running container uses:
docker inspect -f \
'{{range $index, $value := .Config.Env}} {{$value}}{{println}}{{end}}' \
container_id- Run
docker psand check if the port mapping is correct, i.e. you should see0.0.0.0:8000->8000=host_localip:host_port->docker_port - Port mapping annotation for
docker run -p 8000:8000 ...=HOST:DOCKER - For local development you need to use host port
8000to be able to use the Google Authentication in the App - Set
AMPLICON_ENV_PORTif you want to use another port on the host machine, then rebuild the docker image. - If you get the error
permission denied/read only databaseplease set the read-write permissions on your local machine to777for the followingsudo chmod 777 logs/ tmp/ .aws/ caper/caper.sqlite3 -R - If you have an older version of docker
docker composemay not be available and you will need to installdocker-composeand use that, replacingdocker composewithdocker-compose. - Error:
unix /var/run/docker.sock: connect: permission denied-> see - If you need to run as a non-root user (rare), please set
UIDandGIDin your.envfile to match the hostUIDGID, or run as so:env UID=${UID} GID=${GID} docker compose -f docker-compose-dev.yml up - Make sure all folders which are mounted as volumes at runtime are created upfront (below for development):
cd AmpliconRepository; mkdir -p logs tmp .aws .git - My local
mongodbinstance is not running or you getampliconrepository-mongodb-1 exited with code 14? Try docd AmpliconRepository; rm -rf dataand restart usingdocker-compose
These datasets are ready to upload to the site for testing purposes.
- Work on branches and open pull requests to merge changes into main.
- Please ensure that you do not commit
caper.sqlite3along with your other changes. - PR reviewers, please check that
caper.sqlite3is not among the changed files in a PR. - When merging a PR, please do the following steps:
- pull the branch in question and load in local deployment
- at minimum, test the following pages to see if everything looks right:
- home page
- CCLE project page
- load a random sample in CCLE
- Please see the wiki page on using the development server.
- Please see the wiki page on admin login.
The test suite is organized into several tiers by speed and prerequisites, all driven by pytest from the repository root.
| Marker | Description | Prerequisites |
|---|---|---|
integration |
Unit-style tests against live MongoDB; fast (< 5 s each) | MongoDB running |
slow |
Full aggregation pipeline per test (several minutes each) | MongoDB + AmpliconSuiteAggregator |
functional |
End-to-end view tests that depend on pre-loaded datasets | Everything above |
browser |
Playwright browser tests; require a running dev server | Everything above + dev server |
The same environment you use to run the development server is required:
-
Virtual environment active — activate whichever environment you used during setup:
source ampliconenv/bin/activate # python venv # or conda activate ampliconenv # conda
-
Install the test runner (one-time, if not already present):
pip install pytest # For browser tests only: pip install pytest-playwright && playwright install chromium
-
MongoDB running locally — the tests write to the
caper-devdatabase onlocalhost:27017:mongod --dbpath ~/data/db -
Environment variables loaded — source
config.shfrom thecaper/directory:source caper/config.shThe tests read
caper/config.envautomatically, butconfig.shmust have been sourced at least once in the current shell so that shell-level exports are present. -
AmpliconSuiteAggregator available (for
slowandfunctionaltests only) — confirmAGGREGATOR_DEV_PATHinconfig.shpoints to a valid aggregator installation. Tests that use sample-name remapping require v6 or later. -
Test datasets present — place the following files in
test_data/:one_amprepo_sample.tar.gz+one_amprepo_sample.xlsx— 1 sample, hg19 (tracked in git)Contino_unagg_040423.tar.gz— 9 samples, hg38 (download from the shared Google Drive)two_hg38_samples_no_ecdna.tar.gz— 2 hg38 samples, no ecDNA (Google Drive)
The testing datasets are available on Google Drive.
All commands are run from the repository root (where pytest.ini lives).
Fast integration tests only (no aggregation; safe to run any time):
pytest -m "integration and not slow and not functional and not browser" -vFull integration + functional tests (requires AmpliconSuiteAggregator; ~10 min):
pytest -m "integration and not browser" -vEnd-to-end project lifecycle (slow, creates and aggregates real projects):
pytest -m "slow and integration" -vBrowser tests (requires a running dev server on port 8000):
# Terminal 1: start the dev server — must be from THIS repository's caper/ directory
cd caper && python manage.py runserver
# Terminal 2: run browser tests
pytest -m browser --base-url http://localhost:8000 -vImportant: The dev server and the pytest process share a SQLite database (
caper/caper.sqlite3). Two tests —test_authenticated_user_sees_create_formandtest_email_password_login_form_works— inject test users and sessions directly into that database. If the server is started from a different repository clone those tests will skip automatically with a diagnostic message rather than fail.
Expected output for fast integration tests with a correctly configured environment:
tests/test_api.py::test_background_task_status_returns_200 PASSED
tests/test_error_handling.py::test_create_project_without_file PASSED
tests/test_error_handling.py::test_project_page_nonexistent_id PASSED
tests/test_error_handling.py::test_download_nonexistent_project PASSED
Pushes and pull requests to main automatically run the fast integration tests via
GitHub Actions (.github/workflows/tests.yml). The workflow spins up a MongoDB 6
service container and runs pytest -m "integration and not slow and not functional and not browser".
Slow, functional, and browser tests are excluded from CI because they require AmpliconSuiteAggregator, large test datasets, and a running dev server.
Each test removes all artifacts it created — MongoDB documents, tmp/ directories, and S3
objects — in a finally block, so cleanup happens even when a test fails.
AmpliconRepository exposes a read-oriented REST API that lets you list projects, fetch sample metadata, and download project archives — all without a browser.
Public projects are accessible without any credentials. Private projects require an API token.
- Log in to ampliconrepository.org (Google, Globus, or username/password).
- Go to your Profile page.
- Under Developer API Token, click Generate / Regenerate Token.
- Copy the token immediately — it is shown only once.
Pass the token on every request:
-H "Authorization: Token <your-token>"Tokens can be revoked at any time from the Profile page.
All endpoints are under https://ampliconrepository.org/api/v1/.
GET /api/v1/projects/
Returns all projects visible to the caller. Without a token, only public projects are returned. With a token, private projects where you are a project member are also included.
Optional query parameter
| Parameter | Description |
|---|---|
name |
Case-insensitive substring filter on project name |
Example
# All public projects
curl https://ampliconrepository.org/api/v1/projects/
# Your public and private projects
curl https://ampliconrepository.org/api/v1/projects/ \
-H "Authorization: Token <your-token>"
# Filter by name
curl "https://ampliconrepository.org/api/v1/projects/?name=CCLE" \
-H "Authorization: Token <your-token>"Response — JSON array of project objects:
[
{
"id": "64a1b2c3d4e5f6a7b8c9d0e1",
"project_name": "CCLE_2023",
"description": "Cancer Cell Line Encyclopedia amplicon calls",
"sample_count": 542,
"visibility": "public",
"date": "2023-09-15",
"publication_link": "https://doi.org/...",
"creator": "jsmith",
"reference_genome": "hg38",
"AA_version": "1.3",
"AC_version": "1.2",
"oncogenes": ["MYC", "EGFR"],
"classifications": ["BFB", "ecDNA"]
}
]GET /api/v1/projects/<id>/
Returns metadata for a single project. Returns 404 if the project does not exist; returns 401 if the project is private and no valid token is supplied.
Example
curl https://ampliconrepository.org/api/v1/projects/64a1b2c3d4e5f6a7b8c9d0e1/ \
-H "Authorization: Token <your-token>"Response fields are the same as the list endpoint.
GET /api/v1/projects/<id>/samples/
Returns per-sample metadata for every sample in the project. GridFS file-ID fields (Features, Sample_metadata_JSON, Sample_files_JSON) are stripped from the response.
Example
curl https://ampliconrepository.org/api/v1/projects/64a1b2c3d4e5f6a7b8c9d0e1/samples/ \
-H "Authorization: Token <your-token>"Response — JSON array of sample objects:
[
{
"run": "run1",
"Sample_name": "GBM39",
"Cancer_type": "GBM",
"AA_amplicon_number": 1,
"Classification": "ecDNA"
}
]GET /api/v1/projects/<id>/download/
Downloads the project .tar.gz archive.
- S3-backed deployments — returns HTTP 302 to a time-limited presigned URL (valid 10 minutes).
- Local-storage deployments — streams the file directly.
Use curl -L to follow the redirect automatically.
Example
curl -L -O https://ampliconrepository.org/api/v1/projects/64a1b2c3d4e5f6a7b8c9d0e1/download/ \
-H "Authorization: Token <your-token>"POST /api/v1/projects/download/
Content-Type: application/json
Resolve a list of project IDs to their individual download URLs in one call. Useful when downloading many projects programmatically — fetch the URL list, then download each archive in a loop.
Projects that do not exist, have no archive, or are inaccessible to the caller appear in skipped rather than raising an error.
Request body
{"ids": ["64a1b2c3d4e5f6a7b8c9d0e1", "64a1b2c3d4e5f6a7b8c9d0e2"]}Example
curl -X POST https://ampliconrepository.org/api/v1/projects/download/ \
-H "Authorization: Token <your-token>" \
-H "Content-Type: application/json" \
-d '{"ids": ["64a1b2c3d4e5f6a7b8c9d0e1", "64a1b2c3d4e5f6a7b8c9d0e2"]}'Response
{
"downloads": [
{
"id": "64a1b2c3d4e5f6a7b8c9d0e1",
"project_name": "CCLE_2023",
"download_url": "https://ampliconrepository.org/api/v1/projects/64a1b2c3d4e5f6a7b8c9d0e1/download/"
}
],
"skipped": ["64a1b2c3d4e5f6a7b8c9d0e2"]
}Then download each archive:
# Download all resolved archives
curl -X POST https://ampliconrepository.org/api/v1/projects/download/ \
-H "Authorization: Token $TOKEN" \
-H "Content-Type: application/json" \
-d '{"ids": ["id1", "id2", "id3"]}' \
| python3 -c "
import json, sys, subprocess
for entry in json.load(sys.stdin)['downloads']:
subprocess.run(['curl', '-L', '-O', entry['download_url'],
'-H', f'Authorization: Token $TOKEN'])
"| Code | Meaning |
|---|---|
| 200 | Success |
| 400 | Bad request (e.g. ids is not a JSON array) |
| 401 | Missing or invalid token, or project is private |
| 404 | Project or archive not found |
| 503 | Download temporarily unavailable (storage error) |
The server is currently running on an EC2 instance through Docker. The ports active on HTTP and HTTPS through AWS Load Balancer. There are two main scripts to start and stop the server.
Note: While we provide a Dockerfile, local deployment of the site using the docker will only properly work on AWS. Local deployment should be done with a local install using the steps above.
This section covers provisioning a fresh EC2 instance. The app container is built on the host and is not published to any registry — it must be built locally. Source code is mounted into the running container at runtime, so routine code updates do not require a container rebuild; only changes to requirements.txt or the Dockerfile do.
- AMI: Ubuntu Server 22.04 LTS
- Instance type: choose based on expected load (t3.medium or larger recommended)
- Security group: open inbound ports for SSH (22), HTTP (80), HTTPS (443), and the app port defined by
AMPLICON_ENV_PORTinconfig.sh; Neo4j ports 7474 and 7687 should be restricted to internal access only - After the instance is running, register it with the appropriate AWS Application Load Balancer target group:
- Production:
ampliconrepo-https - Dev:
dev-ampliconrepository-org
- Production:
SSH into the new instance and install Docker Engine:
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io
sudo usermod -aG docker ubuntu
# Log out and back in for the group membership to take effectTwo separate git checkouts are maintained to allow container rebuilds without interrupting a running server:
- Running server:
/home/ubuntu/AmpliconRepository-<ENV>— the live checkout whose source is mounted directly into the running container (devorprod) - Build directory:
/home/ubuntu/ampRepo_for_docker_build/AmpliconRepository— used only fordocker build; changes here do not affect the running server
# Running server checkout (use AmpliconRepository-dev for the dev environment)
git clone https://github.com/AmpliconSuite/AmpliconRepository.git /home/ubuntu/AmpliconRepository-prod
# Build-only checkout
mkdir -p /home/ubuntu/ampRepo_for_docker_build
git clone https://github.com/AmpliconSuite/AmpliconRepository.git /home/ubuntu/ampRepo_for_docker_build/AmpliconRepositorycd /home/ubuntu/AmpliconRepository-prod # or AmpliconRepository-dev
mkdir -p logs tmp neo4j/conf neo4j/dataPlace config.sh at caper/config.sh inside the running-server checkout. The checkout root is mounted as /srv/ inside the container, so the file will be read from /srv/caper/config.sh at runtime. config.sh contains all environment-specific secrets and settings — database connection strings, OAuth keys, S3 bucket names, and so on. Obtain it from another team member. Do not commit it to git.
MongoDB connectivity uses the existing DocumentDB cluster; the connection string is provided via the DB_URI_SECRET variable in config.sh.
The container mounts /home/ubuntu/.aws so that the application can reach S3. Use one of:
- IAM instance role (preferred for EC2): attach a role with the required S3 permissions to the instance — no credential file is needed
- Access keys: place credentials in
/home/ubuntu/.aws/credentialsin the standard AWS shared credentials format
Build from the build-only checkout so the running server is not affected. The image packages the Python virtual environment and system dependencies; source code is supplied at runtime via volume mount and does not need to be re-baked on every code change.
cd /home/ubuntu/ampRepo_for_docker_build/AmpliconRepository/caper
source caper/config.sh # sets AMPLICON_ENV and other variables
docker build -t genepattern/amplicon-repo:${AMPLICON_ENV} .Neo4j runs as a Docker container. Run the start script from the running-server checkout root (where caper/config.sh is visible at the relative path the script expects):
cd /home/ubuntu/AmpliconRepository-prod # or AmpliconRepository-dev
./start-neo4j-container.shNeo4j data and configuration are persisted in neo4j/data/ and neo4j/conf/ under the checkout root. To stop Neo4j:
./stop-neo4j-container.shcd /home/ubuntu/AmpliconRepository-prod # or AmpliconRepository-dev
./start-server.shThis launches a gunicorn container named amplicon-${AMPLICON_ENV} with the source checkout mounted at /srv/. Confirm it is running with docker ps. Logs are written to the logs/ directory in the checkout root.
- SSH into the EC2 instance (called
ampliconrepo-ubuntu-20.04)- this requires a PEM key
- Go to project directory
cd /home/ubuntu/caper/
- Check to see if the Docker container is running
docker ps(look for a container called amplicon)
- If it is not running, run the start script
./start-server.sh
- SSH into the EC2 instance (called
ampliconrepo-ubuntu-20.04)- this requires a PEM key
- Go to project directory
cd /home/ubuntu/caper/
- Check to see if the Docker container is running
docker ps(look for a container called amplicon)
- If it is running, run the stop script
./stop-server.sh
- Clone repo using https, ssh, or GitHub Desktop to your local machine
- Make changes locally
- Push changes to the main branch of the repository
- Create a release on GitHub
- login to github and go to the releases page at https://github.com/AmpliconSuite/AmpliconRepository/releases.
- Create a new release using a tag with the pattern v.._ e.g. v1.0.1_072523 for version 1.0.1 created July 15, 2023.
- This will create a tag on the contents of the repo at this moment
- a github action will update and commit the version.txt file with the date, tag, commit ID and person doing the release and apply the tag to the updated version.txt
- After the release is published, wait for the "On Release" GitHub Action to finish before deploying. The action force-moves the release tag to the auto-generated
caper/version.txtcommit. - In the site admin UI, go to
/admin-prepare-shutdown/, confirm no background tasks are running, and enable shutdown mode before restarting the server. Shutdown mode prevents new project creation/editing while deployment is in progress and persists across the restart. - SSH into the EC2 instance (called
ampliconrepo-ubuntu-20.04in us-east-1)- this requires a PEM key
- Go to project directory
cd /home/ubuntu/AmpliconRepository-prod/source caper/config.sh
- Pull your changes from Github
git fetch --tags --force origingit checkout tags/<release tag in github>
- If
requirements.txtorDockerfilechanged, rebuild the Docker image from the build-only checkout before restarting:
cd /home/ubuntu/ampRepo_for_docker_build/AmpliconRepositorygit fetch --tags --force origingit checkout tags/<release tag in github>source /home/ubuntu/AmpliconRepository-prod/caper/config.shdocker build -t genepattern/amplicon-repo:${AMPLICON_ENV} .
- For source-only changes, restart the server with the same script as the nightly cron. During server startup it automatically syncs static files to S3:
/home/ubuntu/stop-and-start-repo.sh
- If the Docker image was rebuilt, remove and recreate the app container so it uses the new image:
cd /home/ubuntu/AmpliconRepository-prod/source caper/config.shdocker stop amplicon-${AMPLICON_ENV}docker rm amplicon-${AMPLICON_ENV}./start-server.sh
- Verify the running container was recreated from the expected image and, when dependencies changed, verify the installed package version:
docker ps --filter name=amplicon-${AMPLICON_ENV}docker exec amplicon-${AMPLICON_ENV} bash -lc 'source /opt/venv/bin/activate && python -c "import AmpliconSuiteAggregator as a; print(a.__version__)"'
- Smoke-test the site, then return to
/admin-prepare-shutdown/and disable shutdown mode.
The server writes temporary working directories under ./tmp/ (relative to the project root) during project creation and editing. These are cleaned up automatically by the server, but if disk space runs low you can reclaim it manually. Always check that no project creation or editing is in progress before deleting anything. First, SSH into the EC2 instance and check for active background tasks:
cd /home/ubuntu/AmpliconRepository-prod/caper
python manage.py shell -c \
"from caper.background_tasks import get_background_task_status; import json; print(json.dumps(get_background_task_status(), indent=2))"If active_count is 0, it is safe to remove all temp directories. To see how much space they are using and then remove them:
du -sh ./tmp/*/ # check sizes
rm -rf ./tmp/*/ # remove all temp dirsIf you want to be cautious and leave any directories that may belong to a recently-started task (for example, if you are unsure whether active_count reflects all workers), limit deletion to directories that have not been written to in at least two hours:
find ./tmp -mindepth 1 -maxdepth 1 -type d -mmin +120 -exec rm -rf {} +Note that restarting the server (/home/ubuntu/stop-and-start-repo.sh) also triggers an automatic cleanup of any orphaned temp directories left by previous runs.