chore(build): Ephemeral Environments onboarding step 1

[mirekdlugosz]

What's included

Files necessary for onboarding curiosity to Ephemeral Environments.

This is necessary for App-SRE Jenkins to build curiosity container. We need curiosity container to deploy curiosity on ephemeral cluster. We need curiosity deployed on cluster to verify if it runs and start working on running iqe tests on EE. So we need this PR in to do anything else related to EEs.

This PR includes #862 and one more commit, both rebased on top of ci branch. It's self-contained and should be rebase-able on top of any branch.

Notes

Current build pipeline uses verify script for PR testing and build:prod script for production builds. Neither was used, so right now I just made them aliases to existing scripts. But we can change that if we want to have different scripts for App-SRE Jenkins, Travis and local development.

jest cache is disabled based on request of App-SRE (see "PR Check and Build Deploy" on "Frontend Container Migration Onboarding" in internal consoledot docs).

How to test

$ podman run -i --rm -v ./:/workspace:ro,Z -e NODE_BUILD_VERSION=14 -e APP_DIR="" -e IS_PR=true -e CI_ROOT="" quay.io/cloudservices/frontend-build-container:34070c2
<snip>
run-s -l build:pre build:js build:post test:integration
[build:js        ] webpack 5.69.1 compiled with 2 warnings in 43739 ms                 
[build:post      ] $ bash ./scripts/post.sh                                                                                                                                   
[build:post      ] Cleaning up build resources...                                                                                                                             
[test:integration] $ TZ=UTC jest ./tests --no-cache   
[test:integration] PASS tests/html.test.js
[test:integration] PASS tests/code.test.js
[test:integration] PASS tests/dist.test.js
[test:integration] PASS tests/version.test.js
[test:integration] PASS tests/platform.test.js
[test:integration] 
[test:integration] Test Suites: 5 passed, 5 total
[test:integration] Tests:       9 passed, 9 total
[test:integration] Snapshots:   9 passed, 9 total
[test:integration] Time:        3.848 s
[test:integration] Ran all test suites matching /.\/tests/i.
$ echo $?
0

Why?

App-SRE Jenkins will use frontend-build.sh@insights-frontend-builder-common script to build container.

Container is built by quay.io/cloudservices/frontend-build-container container, with source code available in insights-platform/frontend-build-container repository in internal gitlab instance. That container basically sets specific node version and runs yarn install --immutable. Then it will call yarn verify (if IS_PR=true) or yarn build:prod (if IS_PR=false). Various parts afterwards kind of expect dist directory to be available, so you can presume verify is supposed to run tests and build.

As a side note, we can provide our own build logic in ci.sh script.

Example

N/A

Updates issue/story

N/A

[codecov-commenter]

Codecov Report

Merging #928 (08744dc) into ci (a70f92c) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##               ci     #928      +/-   ##
==========================================
+ Coverage   94.21%   94.23%   +0.02%     
==========================================
  Files         128      128              
  Lines        3958     3958              
  Branches     1550     1550              
==========================================
+ Hits         3729     3730       +1     
+ Misses        211      210       -1     
  Partials       18       18              

Impacted Files	Coverage Δ
src/common/helpers.js	100.00% <0.00%> (+1.66%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a70f92c...08744dc. Read the comment docs.

[cdcabrera]

@mirekdlugosz I was unable to get the podman instance to fire off as verification and ended up receiving an error that seems to persist after attempting to run the command above. This may have to do with podman and my machine not being a linux box, unable to mount file ... seems to be an ongoing issue.

Error: statfs [local directory]/curiosity-frontend: no such file or directory

Anyway, that being found. I went ahead and broke out the ephemeral environment NPM scripts so we can avoid stepping on any existing processes used by GitHub actions and local development.

And finally given that both pr_check.sh and build_deploy.sh are almost identical ... I'd need your help testing this... if we could end up pulling in the package.json engine entry since it already contains the Node/engine version used by the GUI, see line 16 package.json. Pulling that instead of hardcoding it that'd be one less thing to track when the GUI jumps Node versions (which we're coming up on with a jump to Node 16)

export NODE_BUILD_VERSION=`node -e 'console.log(Number.parseInt(require("./package.json").engines.node.replace(/[\D0]/g, ""), 10))'`

[mirekdlugosz]

Confirmed that setting NODE_BUILD_VERSION dynamically works:

$ export NODE_BUILD_VERSION=`node -e 'console.log(Number.parseInt(require("./package.json").engines.node.replace(/[\D0]/g, ""), 10))'`
$ podman run -i --rm -v ./:/workspace:ro,Z -e NODE_BUILD_VERSION -e APP_DIR="" -e IS_PR=false -e CI_ROOT="" quay.io/cloudservices/frontend-build-container:34070c2
Now using node v14.19.1 (npm v6.14.16)                                                                                                                                        
Creating default alias: default -> 14 (-> v14.19.1)                                                                                                                           
Now using node v14.19.1 (npm v6.14.16)
...

Same command will work after changing package.json to require Node 16.

One note: this requires bumping only major number in node version. I.e. when requiring Node >=16.10.0, this command will return 161.

I can't really help with containers on Mac issues. If you can try with Docker, that would be good enough (in fact, build scripts have docker command hardcoded).
Also, what is [local directory]/curiosity-frontend? Does that path exist? Are you running container from root of git repository?
Frontend build scripts have some code to fiddle with paths during build... I don't need to change that, but looking at WORKSPACE and APP_ROOT might lead somewhere.

[cdcabrera]

@mirekdlugosz sure thing on the whole version numbers issue. I'll refine the string replace today add it to this PR then get you to go back through and confirm it works

• [local directory] was a map of my system and where I code from =)

[cdcabrera]

For posterity... purposed branching paths

Align using existing branches

This would be easiest when the GUI has a release where all branches would be temporarily aligned for a release rebase.

• main = prod-stable
• stage = prod-beta
• qa = goes way OR becomes stage-stable OR becomes qa-stable dependent on the Travis job setup
• ci = main and becomes stage-beta OR qa-beta OR both stage-beta & stable

Minimally align, our chance to reset

This strategy removes the concept of leveraging beta and stable environments for both Prod and Staging, which we have used to our advantage in the past. In theory we could still maintain a prod-beta or stage branch with this if it becomes an issue.

• develop OR dev
  • This would be where all PRs go first. Helps avoid firing the overhead of some epic level checks. Just runs basic Unit and Dev level Integration checks. Does NOT move into any environment. A holding branch.
• main AKA test
  • Merged from develop or directly, this starts the actual... "hey we're ready to start thinking about stuff being in the environment" tests. PR checks for ephemeral kick in. Merges to stage beta and stable
• prod
  • Merged from main only... go from stage to production stable and beta. We no longer make any distinction between stable and beta and leave that for some future where environment variab.... pardon 😃 feature flags pop up. We may still be able to manipulate this with a distinction at the build level, which we currently do based on branches being merged