Add ability to tag projects on BOM upload

[UgniusV]

It would be useful for automation if projects could be tagged on BOM upload.

Current Behavior:

Currently, when uploading BOMs via PUT /v1/bom, we can specify the following properties:

• projectName
• projectVersion
• autoCreate
• bom

This works fine, but in order to tag a project we need to make one more request to POST /api/v1/project with the following payload:

{
   "uuid":"ad143ba-1c1d-40ca-8054-2cf57f101206",
   "name":"SampleProject",
   "version":"2022-05-30 11:18:08",
   "classifier":"APPLICATION",
   "tags":[
      {
         "name":"production"
      }
   ],
   "active":true
}

This is cumbersome for automation processes, it would be nice if we could upload BOM & tag the project with a single request.

Proposed Behavior:

Add projectTag as an accepted field to PUT /v1/bom.

Inside BomResource class PUT /v1/bom handler - accept a tag field & use it when creating a project.
Currently, we have the following code: null is being passed in as a tag parameter to qm.createProject

if (hasPermission(Permissions.Constants.PORTFOLIO_MANAGEMENT) || hasPermission(Permissions.Constants.PROJECT_CREATION_UPLOAD)) {
    project = qm.createProject(StringUtils.trimToNull(request.getProjectName()), null, StringUtils.trimToNull(request.getProjectVersion()), null, null, null, true, true);
    //TODO - If portfolio access control is enabled, retrieve the principal (ApiKey only) and automatically grant access to the project to the team the key belongs to.
}

It would be better to use null for a tag when no tag is provided by the user, but if the tag is provided - use it.
E.g. pseudocode

project = qm.createProject(StringUtils.trimToNull(request.getProjectName()), null, StringUtils.trimToNull(request.getProjectVersion()), request.getProjectTags(), null, null, true, true);

Cheers

[valentijnscholten]

I like this proposal, but why not support projectTags (so plural)?

[UgniusV]

I agree - providing multiple project tags would be even better

[nscuro]

Great suggestion! What would the desired behavior be if the project already exists?

1. Ignore the tags
2. Only add tags from the request, but don't remove any existing tags from the project
3. Update the project to only have the tags provided in the request

[UgniusV]

I personally think that option number three is the best one. This way the behavior is consistent with the /api/v1/project endpoint. E.g if we post the following payload to POST /api/v1/project:

{
   "uuid":"ad143ba-1c1d-40ca-8054-2cf57f101206",
   "name":"SampleProject",
   "version":"2022-05-30 11:18:08",
   "classifier":"APPLICATION",
   "tags":[
      {
         "name":"production"
      },
      {
         "name":"another-tag"
      }
   ],
   "active":true
}

The existing tags are overridden with the ones from the the request: production & another-tag.

So I think it makes sense that tagging projects on SBOM upload should work the same

[sephiroth-j]

love to see this coming. Adding tags during BOM upload has been on the wish list for a while now (#586).

[adioe3]

Why not just allow users to decide how to handle tags? Just provide a tagMergeStrategy or whatever field so it's something like:

{
   "uuid":"ad143ba-1c1d-40ca-8054-2cf57f101206",
   "name":"SampleProject",
   "version":"2022-05-30 11:18:08",
   "classifier":"APPLICATION",
   "tags":["production", "another"],
   "tagMergeStrategy": "merge", 
   "active":true
}

the merge strategy can then be merge, overwrite, or ignore tho ignoring makes little sense in this context.

Or, to keep things semantically separated provide it as a parameter:

PUT /tags?tagMergeStrategy=merge
Content-Type: application/json

{
   "uuid":"ad143ba-1c1d-40ca-8054-2cf57f101206",
   "name":"SampleProject",
   "version":"2022-05-30 11:18:08",
   "classifier":"APPLICATION",
   "tags":["production", "another"],
   "active":true
}

[valentijnscholten]

I think the most common use case is just to be able to provide some tags when uploading a BOM to not yet existing project. Would it be OK to start with a PR that supports that? If the project exists, tags will just be added to the existing tags.

A more complex implementation with a merge strategy could also be done, but makes things more complex. And it doesn't support all use cases. For example when you want to add 1 tag and remove 1 specific tag. If we want to support that scenario, we would need more fields like addTags: xxxx and removeTags: yyyy possibly supporting wildcards etc.

I worry that the BOM upload endpoint becomes more and more complex. Maybe we should support the basic use case here (add tags) and leave the more complex stuff to the client to use other endpoints to query/update/delete tags?

[szpak]

I've also bumped into that case recently - to do not need to assign tags manually in the app (especially with a way to later display only - let's say: Java projects).

[clemlesne]

Feature would be appreciated. Or, the ability to add/remove tags programmatically liker for policies.

[syalioune]

@clemlesne
You can add or remove project tags programatically using

curl --location '.../api/v1/project' \
--header 'X-API-Key: <api_key>' \
--header 'Content-Type: application/json' \
--data '{
    "uuid": "<project_uuid>",
    "name": "<project_name>",
    "version": "<project_version>",
    "tags": [
        {
            "name": "alioune"
        }
    ]
}'

The tags field is the desired state : any existing tags that are not mentioned explicitly will be deleted.

[JCHacking]

Hi, any new with this?
I would like to have this feature to make the implementation in gh-upload-sbom simple and clean.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.