dependency-track
dependency-track copied to clipboard
Add ability to tag projects on BOM upload
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
I like this proposal, but why not support projectTags
(so plural)?
I agree - providing multiple project tags would be even better
Great suggestion! What would the desired behavior be if the project already exists?
- Ignore the tags
- Only add tags from the request, but don't remove any existing tags from the project
- Update the project to only have the tags provided in the request
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
love to see this coming. Adding tags during BOM upload has been on the wish list for a while now (#586).
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
}
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?
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).
Feature would be appreciated. Or, the ability to add/remove tags programmatically liker for policies.
![image](https://user-images.githubusercontent.com/10001945/226047021-841591ba-69d0-4fd4-af63-f443911fb9bb.png)
@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.