support optional CODE environment/stage via new optional action input codeDomain

[twrichards]

TO BE TESTED VIA https://github.com/guardian/galaxies/pull/155

---

For most applications we have a CODE environment to allow testing amongst devs and select other users before releasing to PROD, and although for static sites this is less relevant, its still useful for certain projects but currently not easily possible with actions-static-site with out ugly workarounds like...

... in order to specify the different domains. The Stage option is then counter intuitive (when CODE variant is selected)...

... lastly the workaround requires the same build of the static side to have two instances of actions-static-site in its CI definition which is wasteful (and no guarantees they're the same).

This PR aims to address that by offering an optional action input codeDomain which if specfied, generates another CFN stack and differing riff-raff.yaml (making use of prefixStagePaths added in guardian/riff-raff#1015).

[twrichards]

BLOCKED: because the app property of the aws-s3 deployment in the riff-raff.yaml is always set to inputs.domain (in conjunction with prefixApp: true to force the domain into the file path) and there doesn't seem to be an option to vary app by stage (or any other way to make use of inputs.codeDomain if CODE is selected for Stage at deploy time in riff-raff.

... will give this some thought? Any ideas @nicl (aside from a riff-raff PR to support varying S3 path by Stage, like templateStagePaths for cfn deploys)

[akash1810]

IIUC this will use the same bucket for CODE and PROD stages, this goes against the recommendations.

I've a strong suspicion that the prefixStage parameter would immediately help here, rather than the proposed prefixStagePaths parameter.

[twrichards]

IIUC this will use the same bucket for CODE and PROD stages, this goes against the recommendations.

@akash1810 currently actions-static-site is single stage (INFRA) and so to achieve what you're saying we'd need to spin up a lower environment for actions-static-site (which could have its own benefits, to test changes to this repo... but then would you want completely legit code environments to be affected by testing of actions-static-site) OR we'd need to change actions-static-site to have a CODE bucket. I imagine it's single stage (INFRA) to save money, and I would liken the situation you're hinting to...

• riff-raff, where we use PROD riff-raff to do things relating to CODE Stage (and many others).
• config buckets, where we store stuff for multiple stages

I think the fact we don't expect one application to affect an other, I personally think that recommendation doesn't warrants a whole extra stack for actions-static-site - I'm looking into how much complexity we'd add by having a sep. bucket for CODE (gut feel is, not worth it).

I've a strong suspicion that the prefixStage parameter would immediately help here, rather than the proposed prefixStagePaths parameter.

Unfortunately we need set the key to the domain name, as per the comment in the file actions-static-site kinda relies on hack, where the app is set to the domain and prefixApp is used to be able to force a dynamic value into the key - prefixStage would merely add CODE or PROD neither of which is useful, given the architecture of actions-static-site... so we do need guardian/riff-raff#1015 here

[twrichards]

I'm looking into how much complexity we'd add by having a sep. bucket for CODE (gut feel is, not worth it).

@akash1810 yeah looking at it, the Go code would need to look across before two buckets before serving, I don't know Go so might struggle...

[twrichards]

@akash1810 yeah looking at it, the Go code would need to look across before two buckets before serving, I don't know Go so might struggle...

actually I've taken a stab at it, in d772b86

[nicl]

In general, think this is really worthwhile - so thank you for doing the work!

My only concern atm is around the fallback store behaviour. It feels like quite surprising behaviour and doesn't sit quite right - both because of the interesting security implications (though low risk, we are still allowing 'code' stuff to potentially leak into prod in strange ways) and because it adds redundant calls.

The alternatives I can think of are:

1. detecting if the request domain is dev-gutools or contains code. in the domain and then using the CODE bucket (downside is that only certain CODE domains would work)
2. adding a separate CODE ALB in the infra stack and registering certs etc against that when stage is CODE (downside: extra $$$)

Should we just go for (2)? Keen to get thoughts anyway.

[nicl]

(Minor - whitespace between if and opening (.)

[nicl]

How important is this feature to you @twrichards ? If absolutely required, we might be better off creating a v3 of this action that has separate buckets and stacks for the core infrastructure. I.e. at the moment we have a single INFRA stack for the ALB, EC2 instance, and bucket. But we could switch to proper CODE and PROD infra stacks here and then update the action to act on the appropriate ALB/bucket as required based on stage (with your codeDomain input useful here). We'd have to migrate existing users to v3, but that shouldn't be too difficult.

Alternatively, the separate stack deployed to 'PROD' (which you mentioned) is an option here - it's not pretty I realise but it keeps the code here simple. At the moment I think galaxies is the only request for a CODE stage, so this might be the pragmatic option until we get more demand?

My concern with the approach here is that we are reading from both buckets even for a CODE stage request, which feels sus. It is also a bit more complicated in the details too - more conditionals.

[nicl]

This is the bit that makes me somewhat uneasy: we are potentially serving the prod bucket via a code domain. The prefixe match should prevent this from happening but fundamentally the CODE path is still attempting to hit PROD data and this doesn't quite sit right.