ASA: SFMS trigger in dev environments
- Dominant language
- Python
- Stars
- 65
- Forks
- 11
- Avg merge
- 21h 25m
- Merged PRs (30d)
- 70
Description
**Describe the task**
Inputs into our production environment, need to also be processed for our development and test environments in openshift.
**Acceptance Criteria**
- [ ] each tiff file that hits our production /sfms/upload endpoint has to result in a /sfms/upload call to every active pull request in development & test.
**Additional context**
- SFMS runs on a BCWS production server, and calls out to our production environment with new output. We need that output to also get pushed into our development environments!
- Calling sfms/upload for each pull request will result in the same file being uploaded multiple times in our development environment. This should be an issue.
- A possible solution, would be a worker that listens for new tiff files on the message queue in production. It would talk to openshift, and find routes in dev that match "https://wps-pr-*.apps.silver.devops.gov.bc.ca/api". It would make a call to each in turn, uploading the tiff file. As an aside, the same worker to exist in the development environment, and to avoid infinite loops, we'd have to configure things to not actually action anything when running in dev.
- **GOTCHA**: Buddy posts to /upload endpoint, prod puts message on queue. Worker in prod reacts to queue message, takes file, calls /upload in all dev PRs. Each dev PR will action the message to process the file, but will need to add logic that checks what env it's in, otherwise dev PRs will be calling dev PRs, causing recursion.
Contributor guide
Research direction
Start at the production /sfms/upload entry point and the message-queue worker that handles new TIFF files. Trace how development pull-request routes are discovered, then define the environment guard that prevents recursive forwarding; done means each active development and test route receives the upload without triggering further fan-out.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend-api-design, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100