Address misleading build task statuses

[drewbo]

Currently there is no indication that a build task will be run for a given build if the build task object isn't created until the build task completes. We should either:

• refactor the build task statuses so that the object is created at build start time and queued later OR
• update the UI to search for build tasks that will be attached to the build at start time (more difficult frontend logic but avoids refactoring the queuing logic)

[sknep]

unreachable scan?

[drewbo]

Proposal for some changes to how build task statuses work, and thoughts on their semantic meaning:

status	internal meaning	user-facing significance
created	when a build kicks off, we create a record of the "to-be-run" build-task, even if it won't kick off until later (e.g. it's waiting for the build to complete)	users want to know that they've correctly registered a built task (or had it registered for them) and will eventually run
queued	the build task is added to the queue to be run. This can happen at the same time as the build (e.g. code security scan) or more generally after the build completes (e.g. site security scan, accessibility scan, page load times, etc)	this might be an insignificant difference for users (feels similar to created) but might let them know that it's properly queued after the build itself has completed. It's also possible we'll have long queue times if many build tasks are being requested simultaneously
processing	the build task is running within a cloudfoundry task	this might give the user confidence that the scan is running and will be done soonish
success	the build task is complete without error	artifact is available for download
error	this can happen in a few ways -- couldn't start/queue properly, failure in the task code itself, unknown third thing -- but is always an "unexpected error" for now	this is never a user issue, so they should always contact us to have it resolved

• (removing tasked and skipped as unused)
• because we are rolling up multiple tasks to display on the build card:
  • we need to think about how to combine statuses
  • for users who don't have any tasks queued, let's leave it blank for now, especially during beta-rollout, when non-enrolled users won't know what it means (it currently says "no scans queued")

[sknep]

looks great to me, and they match the existing build nomenclature.

Someday I think the language could be more friendly... "queued" could be "in queue", and "created" could be something like "scheduled" / "planned". But I wouldn't make that change here/now

rollup could use comma delimited with "and" to list all (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/ListFormat/format)

const scanStatuses = ['created', 'queued', 'success'];

const formatter = new Intl.ListFormat('en', {
  style: 'long',
  type: 'conjunction',
});

return 'Scans ' + formatter.format(scanStatuses));
// Expected output: "Scans created, queued, and success"

ugh we'd need to map them to better outputs, huh?

[drewbo]

I'm fine if the frontend has a separate "translation" file for all of these to help in the rollup/understanding process, as long as these backend statuses seem like they contain the necessary internal information and will map to user facing info

[sknep]

yeah agree. I didn't mean to derail this with frontend label stuff