GHA PR Based Pipeline

[micheal-w-wells]

Between @calebissharp and myself to work on a pr based pipeline using GHA.

The skinny for @ZoeSimon and @LisaMoore1 is this means we can get individual fixes out sooner rather than big bang releases. We can do it now in really sticky situations (and no problem at all for synch job), but it's not very streamlined for the web app or api yet.

I'm making this issue so that it's known to you two that we can switch to what is called a PR based pipeline, which means the test environment looks just like the code in an individual PR, vs everything in the dev branch (what we do now). Doesn't have to be this sprint, but @calebissharp and I might want to look at how much work it would be as getting hotfixes out is important, and we wouldn't get into release limbo as much.

I've set up a jenkins based one for Invasives so I know how it works, but we would be using github actions as jenkins is on its way out and comes with his own suite of issues. @calebissharp had suggested another platform, however NRM and platform services wants teams to steer clear from test environments that aren't openshift like production, so we're going with openshift + github.

@calebissharp @ZoeSimon we should work out what's TODO for this one once we size it all Lisa can decide if it's something we do before the next big round of features/releases (but after this release) or if it waits till later.

[calebissharp]

@micheal-w-wells This means we'll have multiple deployments, correct? For example, if you had 5 PRs open, you'd have 5 different URLs where you could see the isolated changes. I just want to make sure we're on the same page.

[micheal-w-wells]

@calebissharp yep

[micheal-w-wells]

Gist of what is needed to enhance the current solution:

Right now we use a set of standing deployment configs that subscribe to image changes, and from github we trigger the build and then tag it and we're done.

What is needed to make this a 'truly' PR based approach (not one that just fires on a PR like ours) is to:

• Create a unique ID (or take one from the PR that GH provides) for each deploy
• Use that ID to tag an image
• Use that ID to update or create a deployment config, that also creates a unique route (with PR number or uniqueID)
• Process and/or apply that deployment config
• Check MAX_DEPLOYS var to see if we are over the limit
• Prune old images
• Prune old deployments
• Prune old routes
• PR check should be complete at this stage.

Other notes:

• Accounts needed: One SA to build and tag and prune images
• One SA in each env to image pull (should be already done)
• One SA for each env to process DC / create routes , prune

@fwpushan have a look at this, it's likely identical to what you are trying to do for InvBC