document and revisit `taskType`

[jkowalleck]

Originally posted by @jkowalleck in #222 (comment)

see also: #222 (comment)

@mrutkows reminded: should reflect CI/CD stages. There might be some standardization work done for the wordings.

this ticket is about adding documentation for TaskType and its Enum values.
see

specification/schema/bom-1.5.schema.json

Line 3753 in 8af880d

"taskType": {

[stevespringett]

Is work being done on this for v1.6?

[jkowalleck]

@mrutkows could you provide the missing texts/docs for taskType?
IIRC: You said you would provide them after 1.5 release, because you missed to do so before and ran out of time back then.

FYI @stevespringett i created this ticket as a reminder for CWG, that the docs were missing in 1.5

[mrutkows]

For background, see: https://experienceleague.adobe.com/docs/experience-platform/xdm/ui/fields/enum.html?lang=en

[mrutkows]

See example:

specification/schema/bom-1.6.schema.json

Line 605 in 46ff114

"meta:enum": {

"enum": [
  "design",
  "pre-build",
  "build",
  "post-build",
  "operations",
  "discovery",
  "decommission"
],
"meta:enum": {
  "design": "BOM produced early in the development lifecycle containing inventory of components and services that are proposed or planned to be used. The inventory may need to be procured, retrieved, or resourced prior to use.",
  "pre-build": "BOM consisting of information obtained prior to a build process and may contain source files and development artifacts and manifests. The inventory may need to be resolved and retrieved prior to use.",
  "build": "BOM consisting of information obtained during a build process where component inventory is available for use. The precise versions of resolved components are usually available at this time as well as the provenance of where the components were retrieved from.",
  "post-build": "BOM consisting of information obtained after a build process has completed and the resulting components(s) are available for further analysis. Built components may exist as the result of a CI/CD process, may have been installed or deployed to a system or device, and may need to be retrieved or extracted from the system or device.",
  "operations": "BOM produced that represents inventory that is running and operational. This may include staging or production environments and will generally encompass multiple SBOMs describing the applications and operating system, along with HBOMs describing the hardware that makes up the system. Operations Bill of Materials (OBOM) can provide full-stack inventory of runtime environments, configurations, and additional dependencies.",
  "discovery": "BOM consisting of information observed through network discovery providing point-in-time enumeration of embedded, on-premise, and cloud-native services such as server applications, connected devices, microservices, and serverless functions.",
  "decommission": "BOM containing inventory that will be, or has been retired from operations."
}

[jkowalleck]

re #245 (comment)
@mrutkows could you fork this repo and do the changes in a feature branch from 1.6-dev, and open a pull request targeting that same branch.

[mrutkows]

@jkowalleck I deleted my stale fork and create a new one yesterday (which was the easiest path to pick up all the new branches) ;)
https://github.com/mrutkows/specification

[jkowalleck]

re #245 (comment)
@mrutkows this might help in the future: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[mrutkows]

re #245 (comment) @mrutkows this might help in the future: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

Unfortunately, the new GitHub GUI (the button in the article) will only sync existing branches in your current fork (as well as by default only syncing main/master branch for a new fork unless you uncheck a box)... and the command line would have me compose commands on a per-branch basis...