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
I had the same issue on 2.37.0 and 2.38.1 when no environment is provided in an import-scan call and no environment with the name 'Development' exists. Hence, renaming the default list of environments effectively breaks any API calls to import-scan without the environment parameter. As I found out the hard way, this includes the Dependency Track integration.
I'd expect the environment parameter to be mandatory, or else it should be possible to set a 'default' environment which would then be used if no environment is set in the API call. If a non-existing environment is provided, an HTTP 400 would be ok imho. I wouldn't go auto-creating environments as this is an admin responsibility.
* get or create environment
* honor auto_create_context, update docs
* case of not providing environment
* create base class, re-use code import, reimport
* put common context code in base
* mistyped dict for data
Be informative
DD raises an exception (HTTP-500 - internal server error) if a user uses a name of an non-existing environment in (re)imports
Bug description
ImportScanSerializer.set_context
andReImportScanSerializer.set_context
useswhich is able to handle not defined
environment
but does not handle non-existenting oneSteps to reproduce
Expected behavior
There are 2 options
set_context
is happening outside of AutoCreate contextDeployment method (select with an
X
)Environment information
Logs
The text was updated successfully, but these errors were encountered: