feat/1545 (part 1) initial addition of files from miles repo for live comms website

[riatzukiza]

Summary of Changes

Since the live comms site is over 500 files we already know we want, to make the deployment adjustments easier to review this PR just introduces the files as they already were.

How to Test

List the steps to test the PR
These steps are generic, please adjust as necessary.

cd tdrs-frontend && docker-compose -f docker-compose.yml -f docker-compose.local.yml up -d
cd tdrs-backend && docker-compose -f docker-compose.yml -f docker-compose.local.yml up -d 

1. Open http://localhost:3000/ and sign in.
2. Proceed with functional tests as described herein.
3. Test steps should be captured in the demo GIF(s) and/or screenshots below.

Demo GIF(s) and screenshots for testing procedure

Deliverable 1: Accepted Features

Performance Standard(s): At the beginning of each sprint, the Product Owner and development team will collaborate to define a set of user stories to be completed during the sprint. Acceptance criteria for each story will also be defined. The development team will deliver code and functionality to satisfy these user stories.

Acceptable Quality Level: Delivered code meets the acceptance criteria for each user story. Incomplete stories will be assessed and considered for inclusion in the next sprint.

• Look up the acceptance criteria in the related issue; paste ACs below in checklist format.
• Check against the criteria:

As Product Owner, @lfrohlich will decide if ACs are met.

Deliverable 2: Tested Code

Performance Standard(s): Code delivered under the order must have substantial test code coverage. Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality Level: Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: ___ (see https://github.com/raft-tech/TANF-app README coverage dashboard)
  • Backend coverage: ___ (see https://github.com/raft-tech/TANF-app README coverage dashboard)

Deliverable 3: Properly Styled Code

Performance Standard(s): GSA 18F Front- End Guide

Acceptable Quality Level: 0 linting errors and 0 warnings

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Does this PR change any linting or CI settings?

Deliverable 4: Accessible

Performance Standard(s): Web Content Accessibility Guidelines 2.1 AA standards

Acceptable Quality Level: 0 errors reported using an automated scanner and 0 errors reported in manual testing

• Does this PR complete the epic?
• Are links included to any other gov-approved PRs associated with epic?
• Does PR include documentation for Raft's a11y review?
• Did automated and manual testing with @iamjolly and @ttran-hub using Accessibility Insights reveal any errors introduced in this PR?
  • See the full Accessibility Assessment plan here.

Deliverable 5: Deployed

Performance Standard(s): Code must successfully build and deploy into the staging environment.

Acceptable Quality Level: Successful deployment by assigning a 'Deploy with CircleCI - {env}' label

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

Performance Standard(s): Summary of user stories completed every two weeks. All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented, including system diagram. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. All non-inherited 800-53 system security controls are documented in the Open Control or OSCAL format and HHS Section 508 Product Assessment Template (PAT) are updated as appropriate.

Acceptable Quality Level: Combination of manual review and automated testing, if available

• If this PR introduces backend code, is that code documented both inline and overall?
• If this PR introduces frontend code, is that code documented both inline and overall?
• If this PR introduces dependencies, are their licenses documented?

Deliverable 7: Secure

Performance Standard(s): Open Web Application Security Project (OWASP) Application Security Verification Standard 3.0

Acceptable Quality Level: Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?

Deliverable 8: Context

• Performance Standard(s): Code must be understandable and contextualized for the reviewers possess the knowledge and background necessary for analysis and constructive criticism to take place.

• Acceptable Quality Level: Code submitted in the pull request has context.*

• Does this pull request contain sufficient inline comments providing relevant context for code snippets?
• Is the code understandable and lucid?
• Does this pull request provide background for why coding decisions were made?
• Can you as a reviewer explain and take ownership of these elements presented in this code review?

[jorgegonzalez]

Are we committing the whole USWDS library here? @reitermb Can't we just link to the source in the relevant html files?

[jorgegonzalez]

I only point that out because this PR introduces a nontrivial amount of potentially unneeded files and code

[jorgegonzalez]

Are we committing the whole USWDS library here? @reitermb Can't we just link to the source in the relevant html files?

@riatzukiza @reitermb ?

[codecov]

Codecov Report

Merging #1555 (0a1e08a) into raft-tdp-main (a205a8e) will decrease coverage by 0.02%.
The diff coverage is n/a.

❗ Current head 0a1e08a differs from pull request most recent head afe5758. Consider uploading reports for the commit afe5758 to get more accurate results

@@                Coverage Diff                @@
##           raft-tdp-main    #1555      +/-   ##
=================================================
- Coverage          97.58%   97.55%   -0.03%     
=================================================
  Files                 80       80              
  Lines               1901     1884      -17     
  Branches             249      245       -4     
=================================================
- Hits                1855     1838      -17     
  Misses                22       22              
  Partials              24       24              

Flag	Coverage Δ
dev-backend	99.09% <ø> (-0.01%)	⬇️
dev-frontend	94.72% <ø> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
tdrs-backend/tdpservice/core/models.py	100.00% <0.00%> (ø)
tdrs-backend/tdpservice/users/api/utils.py	100.00% <0.00%> (ø)
tdrs-backend/tdpservice/users/serializers.py	100.00% <0.00%> (ø)
tdrs-frontend/src/components/Header/Header.jsx	100.00% <0.00%> (ø)
...ackend/tdpservice/users/api/login_redirect_oidc.py	100.00% <0.00%> (ø)
...ckend/tdpservice/users/api/logout_redirect_oidc.py	100.00% <0.00%> (ø)

---

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 a205a8e...afe5758. Read the comment docs.

[riatzukiza]

I only point that out because this PR introduces a nontrivial amount of potentially unneeded files and code

I can't find an official CDN, and all their documentation suggests the best way to include it is through npm. How do you suggest we do this?

[jorgegonzalez]

I can't find an official CDN, and all their documentation suggests the best way to include it is through npm. How do you suggest we do this?

A non-official CDN will more than suffice for these purposes, in my opinion https://www.jsdelivr.com/package/npm/uswds

[jorgegonzalez]

unpkg is also a good option https://unpkg.com/

[riatzukiza]

For reference, there is a conversation in place about an official CDN
uswds/uswds#4298

[riatzukiza]

Maybe we can also pin point exactly which of these assets we need, and which were just added as boilerplate when you created the github website? @reitermb cc @jorgegonzalez

[jorgegonzalez]

Is that really worth the effort over just using the CDN?

[reitermb]

Is this mainly about all the assets (e.g. icons) and having both minified and non versions of css, JavaScript, etc...?

I'm open to suggestions on hosting those anywhere (and pruning out unneeded files for that matter) so long as it doesn't impact our ability to make tweaks to them/supplement them/add to them.

[riatzukiza]

sort of a side thing, this is 500+ files, the CDN gets rid of 3 or 4 of them. A lot are images, fonts, etc. I am wondering if we can get rid of some of those.

[jorgegonzalez]

Hmm I thought it could have gotten rid of more

[jorgegonzalez]

Approving this as including all this in the repo seems to be the simplest solution at this time

[riatzukiza]

@jorgegonzalez from the looks of it, there are a bunch of style files that are important to USWDS that I don't think would get included with the js files. I think there is more to it than that.

[jorgegonzalez]

Those CDNs don't just serve js though

[riatzukiza]

I managed to get rid of 400 files, the whole source code seemed to be incldued and it wasn't needed.

[ADPennington]

👍🏾