Build and deploy check-api batch jobs via Terraform

[sonoransun]

Description

This change is required for the batch job updates via Terraform. Note that all batch jobs are using this new deployment mechanism once merged.

References: CV2-4345, DEVOPS-484, DEVOPS-498

How has this been tested?

This is the usual build and deploy configuration.

Things to pay attention to during code review

PLEASE DO NOT MERGE until the sysops part of this has also been merged. The sysops batch job workflow changes MUST BE merged before this pull request. Thank you!

Checklist

• I have performed a self-review of my own code
• I considered secure coding practices when writing this code. Any security concerns are noted above.
• I have commented my code in hard-to-understand areas, if any
• I have made needed changes to the README
• My changes generate no new warnings

[caiosba]

Thanks, Martin. This is only DevOps stuff, so I'm assigning to Aaron and Doci for review.

[codeclimate]

Code Climate has analyzed commit 3c0be9f and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (100% is the threshold).

This pull request will bring the total coverage in the repository to 100.0% (0.0% change).

View more on Code Climate.

[dmou]

why are you overwriting the push job with batch deployments?

[sonoransun]

why are you overwriting the push job with batch deployments?

I didn't realize the existing images were being used. I changed this image build step because the existing images (which deploy to /live/check-api, /qa/check-api, and /batch/check-api via GitLab CI use the production/Dockerfile which is somewhat different.

There is a tag step in this workflow that is unused, eventually I expect this workflow to deploy to QA and Live, along with Batch jobs.

Maybe this is a good time to use the GitHub images in the check-api repo with the default Dockerfile as intended in our brave new world. Let me try that and then I can revert these changes accordingly.

[dmou]

I didn't realize the existing images were being used. I changed this image build step because the existing images (which deploy to /live/check-api, /qa/check-api, and /batch/check-api via GitLab CI use the production/Dockerfile which is somewhat different.

There is a tag step in this workflow that is unused, eventually I expect this workflow to deploy to QA and Live, along with Batch jobs.

Maybe this is a good time to use the GitHub images in the check-api repo with the default Dockerfile as intended in our brave new world. Let me try that and then I can revert these changes accordingly.

if this is blocking I think it's fine to just create a separate job and not overwrite this one. it's in place for future deployments with one dockerfile, yes, but is also writing to an ECR repo that has a deletion policy in place so it's fine to continue using. the interleaving changes are a little confusing to review since they're intended for entirely different purposes imo

[huslage]

LGTM