You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current state, 1 SCAVA project = 1 mailing list + 1 forum + 1 issue tracker + 1 ...
It is a one-to-one relationship between the registered project and source of the same kind.
The more I am thinking about it, the more I'm convinced that the ability to have "multiple sources" attached to a single project is something useful as it is a pretty common scheme to consider a project as a "group" of resources, for instance a combination of :
several mailing lists (usually, some of "users", "news",
"dev"... etc)
several issue trackers (whenever there are several VCS repos which happens frequently in GitHub/GitLab)
As a matter of example. If you take the project "XWiki" , it has the following sources:
At this point as an end user, even if I get to add ~50 SCAVA projects to match the most interesting JIRA projects and both git repos, I would have to manage the same amount of tasks in SCAVA.
Then I suppose it means the same amount of endpoints to be accessed from the REST API for the various tool to collect the values.
It's a room for improvement I guess.
Regards,
The text was updated successfully, but these errors were encountered:
@borisbaldassari : I realised per your recent screenshots in crossminer/scava#346 that it's possible to create a scava project with several sources... this, 6 months later !
Indeed, in the "create project" form you can click the button several several times...
Are you using the API to do that ? Are you providing an array to /projects/create ?
Hi @mhow2!
I'm using the import eclipse project feature, so I've no idea how to do it through the webui/api..
As a sidenote, I do have the opposite problem: we can afford only one git repo in our case (perf issues) so I need to remove some of the defined repos so only one of them remains..
😆 OK, now I understand. On my side, when I need more control on the properties of a project, I'm using /projects/create and I'm passing the related JSON structure from a config file https://github.com/crossminer/third-party-rest-clients/blob/master/provision-projects-list.json.dist, see the scavaMeta node. The content of this node is exactly what's the scava API end point mentioned expects. Cheers!
This was already raised during a discussion with @creat89 and @borisbaldassari
In the current state, 1 SCAVA project = 1 mailing list + 1 forum + 1 issue tracker + 1 ...
It is a one-to-one relationship between the registered project and source of the same kind.
The more I am thinking about it, the more I'm convinced that the ability to have "multiple sources" attached to a single project is something useful as it is a pretty common scheme to consider a project as a "group" of resources, for instance a combination of :
"dev"... etc)
As a matter of example. If you take the project "XWiki" , it has the following sources:
JIRA: https://jira.xwiki.org/ (dozens of projects here)
Git repos in the Org : https://github.com/xwiki/ at least 2 of them are critical for the project
At this point as an end user, even if I get to add ~50 SCAVA projects to match the most interesting JIRA projects and both git repos, I would have to manage the same amount of tasks in SCAVA.
Then I suppose it means the same amount of endpoints to be accessed from the REST API for the various tool to collect the values.
It's a room for improvement I guess.
Regards,
The text was updated successfully, but these errors were encountered: