EKS Testing: Reliability team; Create a Postman docker image

[jennb33]

User Story

As the Reliability team resources, We need to create and deploy a postman docker image, So that this part of the functional requirements is complete.

Issue Description

Create a postman docker image: a “vets-api postman” docker image be built & published as part of the vets-api github build workflow to ECR. This container would have the Postman/Newman executables as well as the associated postman scripts.

Tasks

• [ ] Docker image to contain postman executable and configurations
• [ ] Created and versioned at build
• [ ] Docker image needs to live in this new directory
• [ ] Modify these build workflows as necessary
• [ ] Document the build of the docker image, including any information that may be prudent to understand for other dev resources.

Success Metrics

Docker image has been created and integrated without causing any new errors or issues.

Acceptance Criteria

• [ ] Postman docker image that has been created and versioned at build, residing in the new directory.

---

Validation

Assignee to add steps to this section. List the actions that need to be taken to confirm this issue is complete. Include any necessary links or context. State the expected outcome.

[IGallupSoCo]

It wasn't explicitly using a standalone Postman docker image, but I made a bunch of headway on Postman integration for Preview Environments a while back before putting it down for other priorities. I'll pull together links for the ticket and branch.

[IGallupSoCo]

• Initial work ticket
• Current work's state
• prt-control-plane repo branch with the unfinished work

[IGallupSoCo]

To summarize the direction we took with the work for PEs:

• The test collection execution was directly integrated into the build-and-publish workflow.

  

  First, it takes the just-built image and spins up containers for both postgres and the control plane. Then it installs Newman, a Postman CLI utility, checks up on the control plane container, and sets it up for testing the control plane container at port 50000. If the tests fail, the GHA runner will exit the workflow and leave the publish job undone. Either way, logs should have been captured by docker for review as needed. The containers are then destroyed.
  
  What's left:

• The collection currently stored within the prt-control-plane repo on that branch is a dummy collection that will neither pass nor do anything useful. I was working with it before the vets-api EKS initiative work, and understood far less about how to properly configure the collection or about the endpoints that would be under test.

• As this effort has moved on and progressed, the configurations set within some of my added commands are almost certainly outdated or may need a complete rework

• The test cleanup job was written at a time when we believed we only needed one container running to successfully run the test collection. It needs updated to destroy both test containers used.

I would like to think that most of this could be adapted for the EKS effort as well, but I suspect I'm missing key points of nuance. Feel free to DM me or tag me in one of the relevant Slack channels with any further questions.