Wireframe how the UI for build tasks can be integrated into the current app build structure

[apburnes]

User stories:

• As a developer or product owner responsible for ensuring that my agency's Pages site is secure and usable, I want to see if my code and site have any obvious security or usability problems.
• As a developer responsible for addressing security or accessibility issues for a Pages site, I want to know precisely where any discovered issues are, and see documentation or remediation steps for each issue.
• As a developer adding new features, or a content manager adding new content, I want to make sure that I am not introducing new security or usability/accessibility problems when I contribute to my Pages site, even on non-production branches.
• As a compliance analyst or site manager responsible for ensuring that my agency's technology products fulfill 21st Century IDEA, ATO, and SSP requirements, I want to directly access and keep records of my site's required scans.

What is this for? Is it like GitHub's Actions, or GitLab's jobs?

Build tasks will be used primarily (or perhaps solely) to run automated tests on customer sites, either on the code itself at the beginning of the build, or on the generated site build after it is available on a preview link. They run concurrently, not in series, and do not imply a pipeline.

Notably, these tasks are not intended to be blocking -- which is to say, they will not fail or cancel a build, regardless of whether they complete or indicate concerns.

For now, the first/only scan we'll offer is a ZAP vulnerability scan, which is intended to support BYO ATO customers provide monthly documentation that they meet required vulnerability scanning requirements. Later scans may support additional requirements identified for 21st Century IDEA compliance and other laws.

What about site scanning? Can anyone else see the customer site scans?

The site scanning team has identified ZAP scans in their candidate scans but have not yet implemented them or any other vulnerability/penetration testing scans. Additionally, as publishing these scans broadly would bring more attention to vulnerable Pages sites, these scan results will only be available to existing site/org users. That said, these vulnerabilities are public knowledge, which is why CISA urges technology owners to remediate any issues found within 30 days.

Potential Rollout

Team is deciding whether to enable scans by default for all customer sites and branches, or to make scans configurable, either by site or by branch. Considering cost of scans, value to customers, etc.
Will likely identify this as a beta or experimental feature, so that we can more easily make adjustments without disrupting users. Intend to refine with user feedback after initial rollout. Testing "scans" rather than "tasks" as the nomenclature for usability -- and to make sure not to confuse with concepts like "jobs", "actions", "workflows", "pipelines" etc -- as those imply more control over the activities as well as concepts like sequencing and gating.

Acceptance Criteria TBD

### Tasks
- [x] Define schema for each task run, as well as each possible task type in the DB
- [x] UI and workflow changes for site settings page (enable/disable tasks)
- [x] UI and workflow for tasks for each build (view/download artifact(s), see task status)
- [x] UI and workflow changes for build history log -- surface a link to tasks and artfacts
- [ ] Draft documentation for build tasks and individual scans available
- [ ] Draft customer communications about build tasks/scans (possibly note experimental feature, feedback welcome)
- [ ] Begin usability testing for build tasks/scans
- [ ] Identify metrics to monitor (& collection method/s) in order to determine feature usage/value to customers

[sknep]

Got a walkthru of the build tasks from Drew this morning, will follow up with next steps & timeline soon.

[sknep]

Strawman for how this might look if we make the tasks customer-controlled and the artifacts viewable in the build logs:

[apburnes]

The ran tasks table and site task settings look great!

For the ran tasks table, I think we can have it on it's own page so it doesn't need share with the build logs page.

A site's build logs page is:

• https://pages.cloud.gov/sites/<site-id>/builds/<build-id>/logs

So a site's build tasks could be at:

• https://pages.cloud.gov/sites/<site-id>/builds/<build-id>/tasks

Also, if you have any thoughts on how we can show the tasks on the build history page.

Do we just have a link to the build's tasks or do we actually show task statuses?

Side note: We've used the accordion component as a catch all and it may not be the right use. If you have an opinion or alternatives, please share.

[sknep]

Some WIP screens from retro demo today:

Tasks per build

https://pages.cloud.gov/sites/<site-id>/builds/<build-id>/tasks

How customers can look at each scan's status and access artifacts

Notice that the filename for the downloadable artifact contains the date the scan was run (maybe timestamp?) and name of the scan run. Also see that we're considering how to collect feedback on this feature, whether email, touchpoints, ???

Build history

https://pages.cloud.gov/sites/<site-id>/builds

How customers will notice / be urged to check scan results

Option 1 -- 3 column with bonus row for latest builds: Option 2 -- 4-column with "actions":

This rolls up the total count of issues aggregated across scans. We assume scans will have some "count" to report, even if it's a score like Lighthouse (where we could set a threshold to meet and compute 0 or 1 based on whether the results meet that threshold). We want to be able to surface significant changes in scan results to the build history without being too disruptive. Need to test whether this draws enough interest.

possibly consider a scans history page similar to the build history page, but lists all scans ever run https://pages.cloud.gov/sites/<site-id>/scans

Site settings for build scans

https://pages.cloud.gov/sites/<site-id>/settings

How customers will be able to enable/disable scans and be introduced to the value/need for scans

Note that we're not sure whether we will enable these by default as they are added, and/or allow customers to directly enable/disable scans, either for the whole site or particular branches/custom domains.

Considering introducing this as a beta/experimental feature to explicitly communicate potential changes and the possibility for customers to have input in the direction of the product.

Build log

https://pages.cloud.gov/sites/<site-id>/builds/<build-id>/logs

How build log pages will refer to scans

Has same header changes to be consistent with new scan details page. btw, is this a log, or logs?

[sknep]

Ok I think these are the final set, but let me know if you have any other comments! @apburnes @drewbo @svenaas

Build history

Hopefully we can make something close to these changes.

Scan results & Build logs

Note that the build info is up at the top of the page

Similar changes to the top of the build logs page, if possible/easy, to keep consistent with scan results

Scan history (?)

Unsure if this is necessary. We'll see repeated sets of tests... I think these are all the reasonable states that should be displayed to the user. The possible states for build tasks that I got earlier was ‘created’, ‘queued’, ‘tasked’, ‘error’, ‘processing’, ‘skipped’, ‘success’, but not sure if it's up to date. Looks a lot like the build state list.

We'd need to put this in the left sidebar so people can find it, i'd probably put it above uploaded files but here's the icon / label:

---

Site Settings

(If/when we make these toggleable)

PS: I know we haven't picked an accessibility scan, but something that does WCAG 2.2 A and AA would be nice, when we get to it. ANDI is here just as placeholder.

[drewbo]

@sknep yeah this looks great. Two very small things:

• I did pull the original list of build task states from the build states: we'll probably only use a smaller subset of that.
• To start, we might have to leave "view build/rebuild" as an option on all builds but we can add that as a fix later on if needed