add flag to clone and configure dataverse-frontend repo

[pdurbin]

The parent issue is here...

• https://github.com/IQSS/dataverse/issues/9347

... but most of the work will happen in this repo.

We should add a new flag to the ec2-create-instance.sh script (in the other issue I suggested -f but now I see it's already taken) to clone and deploy the new dataverse-frontend repo: https://github.com/IQSS/dataverse-frontend

The idea is that, like now with the older frontend, we should be able to run the script to run up the new frontend on a server for demo purposes or for continuous integration.

[pdurbin]

There's a new (currently draft) PR for the frontend:

• https://github.com/IQSS/dataverse-frontend/pull/4

[pdurbin]

Locally as of https://github.com/IQSS/dataverse-frontend/commit/bfdb4cb I ran npm install followed my npm run build. Here's the output from the latter:

$ npm run build

> dataverse-frontend@0.1.0 build
> react-scripts build

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  88.25 kB  build/static/js/main.76fa1bf6.js
  27.93 kB  build/static/css/main.779aae98.css
  1.79 kB   build/static/js/787.db17f31c.chunk.js

The project was built assuming it is hosted at /.
You can control this with the homepage field in your package.json.

The build folder is ready to be deployed.
You may serve it with a static server:

  npm install -g serve
  serve -s build

Find out more about deployment here:

  https://cra.link/deployment

Then I zipped up the "build" directory like this (I'm on a Mac):

$ zip -r build.zip build -x '**/.*' -x '**/__MACOSX'
  adding: build/ (stored 0%)
  adding: build/favicon.ico (deflated 79%)
  adding: build/index.html (deflated 44%)
  adding: build/locales/ (stored 0%)
  adding: build/locales/en/ (stored 0%)
  adding: build/locales/en/helloDataverse.json (deflated 32%)
  adding: build/logo512.png (deflated 1%)
  adding: build/asset-manifest.json (deflated 64%)
  adding: build/static/ (stored 0%)
  adding: build/static/css/ (stored 0%)
  adding: build/static/css/main.779aae98.css (deflated 86%)
  adding: build/static/css/main.779aae98.css.map (deflated 79%)
  adding: build/static/js/ (stored 0%)
  adding: build/static/js/main.76fa1bf6.js.map (deflated 68%)
  adding: build/static/js/787.db17f31c.chunk.js.map (deflated 65%)
  adding: build/static/js/main.76fa1bf6.js (deflated 70%)
  adding: build/static/js/main.76fa1bf6.js.LICENSE.txt (deflated 81%)
  adding: build/static/js/787.db17f31c.chunk.js (deflated 62%)
  adding: build/static/media/ (stored 0%)
  adding: build/static/media/getFetch.40f37ddea2378391108f.cjs (deflated 54%)
  adding: build/static/media/logo.66fab8add84457ce8a83341551572768.svg (deflated 24%)
  adding: build/manifest.json (deflated 52%)
  adding: build/robots.txt (deflated 10%)
  adding: build/logo192.png (stored 0%)

Here it is: build.zip

I guess the next question is, where on the EC2 instance should we unzip build.zip? /var/www/html/dataverse-frontend? Let's see what @MellyGray and @GPortas think! 😄

[pdurbin]

Highly related, I just tested and moved to QA that deploys the SPA as a war file to Payara:

• https://github.com/IQSS/dataverse-frontend/pull/29

(To https://dev1.dataverse.org/spa/ if you must know. And yes, Dataverse proper is also running there at https://dev1.dataverse.org .)

I suppose we could use the same approach here in dataverse-ansible? I'm open to suggestions! 😅

[donsizemore]

@pdurbin just a note that even the current version of RHEL doesn't provide the recommended versions of npm or nodejs; enabling NPM's RPM repo requires disabling appstream due to package conflicts. We want to move to container-based CI anyway; suggestions on how to (cleanly) proceed in the context of Ansible on a RHEL-based system are welcome.

update: I'm considering creating an unprivileged "frontend" service account, which will run NPM's shebang installation script within the confines of its home directory. this will leave installations to fend for themselves regarding security and other updates.

[donsizemore]

closed in #278