Thank you for the feedback. As you have noticed, our rule raises for all constructor calls that are not assigned to a variable. In general, it is a bad pattern to perform an action inside the constructor, but a few high-profile libraries do this, so we have extended the rule to accommodate these exceptions. We could consider doing it for this case as well, and I would need more information about your use case.
What is that folder ../../imports/k8s from which you import the KubeIngress class?
Is it somewhere you re-export a specific library like cdk8s?
Hi Ilia,
Thanks for your answer.
I think broadly it is the case for every Infrastructure as Code libraries. Currently we use three of them:
CDKTF
In this case, things are imported from generated providers as well.
CDK8S
This is the example I shared, and imports can happen from the generated imports or cdk8-plus libraries.
AWS-CDK
Probably, it is even less about exceptions for specific libraries but more about either guiding us to ignore specific constructors and infrastructure as code frameworks,
Hi, I haven’t heard back on this topic for a while. Today I met Berkay Bektas and made him aware of the issue.
He requested to ping you again to remind about the topic.
Can you please let me know if Sonarqube has plans to handle rules for Infrastructure as Code frameworks outlined above?
Hi, I’m also seeing a similar false negative when using the AWS CDK (JS) library. We build up custom constructs that extend classes from AWS CDK, but these are being highlighted by SonarCloud Qube (Cloud), such as: