Add a build step to deploy to EKS

[voidlily]

The eks-control repo orchestrates deployments to different envs, going through dev->staging->prod, with manual steps to go staging and prod

[mitchellhenke]

Is there a specific job this stage depends on? Can we use needs to be more precise?

[voidlily]

Without the use of needs, the dependency is "all jobs in previous stages"

[voidlily]

If you look at https://gitlab.login.gov/lg/identity-idp/-/pipelines/120712 you can see it's currently the rightmost stage

[mitchellhenke]

Right, sorry, I understand that aspect. This job is dependent on deploy_production?

I didn't quite understand the interaction with the deploy to "production" there with the description of deploying to different environments in the PR description.

[timothy-spencer]

Yeah, we should seriously consider renaming the deploy_production job to deploy_reviewapp or something. It's not production, and definitely can be confusing. Probably also need to remove it's environment.name: production stuff too.

[mitchellhenke]

That's kind of why I lean towards using needs to explicitly define the dependencies. I think it's worth renaming deploy_production as well.

[voidlily]

i guess, my main requirements here are "everything" and if later on we add another step to the test phase i want that to automatically get picked up as a requirement? hence the stages thing?

[voidlily]

actually, doesn't the main reviewapp go away now? it would be the same as a continuously deployed dev env that this pipeline also adds?

https://idp.eksdev.identitysandbox.gov/

[voidlily]

if there's no objection i'm just gonna delete that step entirely

[mitchellhenke]

I'd defer to @timothy-spencer on that aspect.

[voidlily]

this needs to be in the actual configs and i don't know how to do that, how do you do that?

[voidlily]

was getting 500 errors around the prepared statements and was trying to figure out why, so i went so far as to make a truth table to figure this out

            value true | value false
socket yes      ?            F
socket no       T            F

if the new config value is supposed to take precedence, then it doesn't matter what the value of the db socket is and we can remove that from the database.yml (and make sure the config change rolls out first before the code change)

if the new config value doesn't take precedence, it means the || should be a &&

[voidlily]

if we want to be more careful with rolling this out we could do a 2 phased thing, first one the old config value takes precedence, then a second wave to remove it once the config change are confirmed out

[mitchellhenke]

if we want to be more careful with rolling this out we could do a 2 phased thing, first one the old config value takes precedence, then a second wave to remove it once the config change are confirmed out

I think it's fine to use the config directly right away as long as the default for both is false.

[voidlily]

default if it's not in the config will raise an error about it not existing so this is already a "breaking change" https://github.com/18F/identity-hostdata/blob/main/lib/identity/hostdata/config_builder.rb#L33

so since we already have to eat a tricky change here yeah we can roll it all together in one commit