Analysis fails with exception when project not created yet in Sonarqube #1

winterheart · 2019-03-25T13:35:06Z

Hello.

I'm trying to test sources with command:

mvn test verify sonar:sonar $MAVEN_CLI_OPTS -Dsonar.host.url=$SONAR_URL -Dsonar.login=$SONAR_TOKEN -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.gitlab.project_id=$CI_PROJECT_ID -Dsonar.gitlab.unique_issue_per_inline=true

But on new projects (that not yet created in Sonarqube) I've got exception:

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.6.0.1398:sonar (default-cli) on project stat.profile: No branches currently exist in this project. Please scan the main branch without passing any branch parameters. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.6.0.1398:sonar (default-cli) on project stat.profile: No branches currently exist in this project. Please scan the main branch without passing any branch parameters.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: No branches currently exist in this project. Please scan the main branch without passing any branch parameters.
    at org.sonarsource.scanner.maven.bootstrap.ScannerBootstrapper.execute (ScannerBootstrapper.java:67)
    at org.sonarsource.scanner.maven.SonarQubeMojo.execute (SonarQubeMojo.java:104)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.sonar.api.utils.MessageException: No branches currently exist in this project. Please scan the main branch without passing any branch parameters.

I have only one branch master and not passing any -Dsonar.branch.* to default command. How can I bypass this error?

The text was updated successfully, but these errors were encountered:

mc1arke · 2019-03-25T14:45:31Z

Can you confirm the following for me please:

What version of Sonarqube you're running
Which plugins you have installed (especially any relating to SCM and Gitlab)?

I suspect this is an oversight in how I've implemented parameter validation and branch configuration, but want to check there's nothing odd being injected by other plugins, or provided by SonarQube's core.

winterheart · 2019-03-25T14:59:26Z

I'm using Sonarqube 7.6 with plugins:

Community Branch Plugin 1.1.0-SNAPSHOT (latest commit 409c4ad)
Git 1.8 (build 1574)
GitLab 4.1.0-SNAPSHOT

dejangeci · 2019-03-25T21:10:55Z

I was about to report the same issue. Tested with Dockerized SonarQube versions 7.4 and 7.7, and 1.1.0-SNAPSHOT (latest commit 409c4ad). Using SonarScanner for MSBuild 4.4.2 that is installed on local machine. 0 other plugins.

Checkout plugin code, build .jar.
Run SonarQube in Docker (new, clean container from image)
Login and generate token for Admin to use in commands
Install plugin and restart SonarQube via gui
Start scan from host machine
SonarScanner.MSBuild.exe begin /k:"DEMO" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="[token]"
Build solution
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild" SolutionFile.sln /t:rebuild
End scanning
SonarScanner.MSBuild.exe end /d:sonar.login="[token]"

SONAR_SCANNER_OPTS is not configured. Setting it to the default value of -Xmx1024m
Calling the SonarQube Scanner...
INFO: Scanner configuration file: C:\Program Files (x86)\Sonar\sonar-scanner-msbuild-4.4.2.1543-net46\sonar-scanner-3.2.0.1227\bin\..\conf\sonar-scanner.properties
INFO: Project root configuration file: *path to properties file*
INFO: SonarQube Scanner 3.2.0.1227
INFO: Java 1.8.0_181 Oracle Corporation (32-bit)
INFO: Windows 10 10.0 x86
INFO: SONAR_SCANNER_OPTS=-Xmx1024m
INFO: User cache: C:\Users\*user*\.sonar\cache
INFO: SonarQube server 7.4.0
INFO: Default locale: "en_US", source code encoding: "windows-1252" (analysis is platform dependent)
INFO: Publish mode
INFO: Load global settings
INFO: Load global settings (done) | time=118ms
INFO: Server id: *id*
INFO: User cache: C:\Users\*user*\.sonar\cache
INFO: Load/download plugins
INFO: Load plugins index
INFO: Load plugins index (done) | time=79ms
INFO: Load/download plugins (done) | time=204ms
INFO: Loaded core extensions:
INFO: Process project properties
INFO: Load project branches
INFO: Load project branches (done) | time=8ms
INFO: Load project pull requests
INFO: Load project pull requests (done) | time=16ms
INFO: Load branch configuration
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 4.802s
INFO: Final Memory: 8M/78M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarQube Scanner execution
ERROR: No branches currently exist in this project. Please scan the main branch without passing any branch parameters.
ERROR:
The SonarQube Scanner did not complete successfully
22:20:50.909  Creating a summary markdown file...
22:20:50.917  Post-processing failed. Exit code: 1

…fied SonarQube returns an empty branch list if the project doesn't already exist which results in an error being thrown telling the user to re-run the scan with no branch parameters set, even if no branch analysis parameters were specified. However, when a project is created through the Web interface, SonarQube automatically creates a default branch named `master` which the scanner picks up as the primary branch and targets if no other parameters are specified. This inconsistency means users can't have SonarQube automatically create projects, but have to use the Web interface to set-up any projects first. To make the setup consistent, the check for no branches existing is extended to also check if any of the branch or pull request parameters have also been specified. This way, if no branches exist but no branch or pull request parameters were specified then a `DefaultBranchConfiguration` instance is returned which points the analysis at the a default `master` branch which SonarQube will create.

SonarQube returns an empty branch list if the project doesn't already exist which results in an error being thrown telling the user to re-run the scan with no branch parameters set, even if no branch analysis parameters were specified. However, when a project is created through the Web interface, SonarQube automatically creates a default branch named `master` which the scanner picks up as the primary branch and targets if no other parameters are specified. This inconsistency means users can't have SonarQube automatically create projects, but have to use the Web interface to set-up any projects first. To make the setup consistent, the check for no branches existing is extended to also check if any of the branch or pull request parameters have also been specified. This way, if no branches exist but no branch or pull request parameters were specified then a `DefaultBranchConfiguration` instance is returned which points the analysis at the a default `master` branch which SonarQube will create.

mc1arke · 2019-03-25T22:16:15Z

The issue seems to be due to overly strict validation in the plugin, and different behavior in SonarQube's response when queried for branches for a project that doesn't exist versus a project that does exist but hasn't been scanned. The plugin had been thoroughly tested against existing projects created through the user interface, but not through the automatic creation method this issue is using.

I've made a change on the bug/issue1 branch, are you able to build a snapshot and run it to confirm if this fixes your issue? If it does then I'll get the branch merged and a new release published.

nixel2007 · 2019-03-25T22:18:23Z

offtopic:
oh god, you are really good in commits commenting!

dejangeci · 2019-03-26T13:47:23Z

Tested bf15e51 changes with SQ 7.4 and 7.7, working fine if project doesn't exist and a branch is not specified.

Works:
SonarScanner.MSBuild.exe begin /k:"DEMO" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="[token]"

Doesn't work if the project doesn't exists first, but branch is specified (same error as before):
SonarScanner.MSBuild.exe begin /k:"DEMO" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="[token]" /d:sonar.branch.name="master"

Specifying "master", which is the default, should not throw errors, right?

This case should also be covered (branch and target same, project doesn't exist)
SonarScanner.MSBuild.exe begin /k:"DEMO" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="[token]" /d:sonar.branch.name="master" /d:sonar.branch.target="master"

Not completely sure how the official version works, but https://github.com/msanez/sonar-branch-community worked with all variants above.

mc1arke · 2019-03-26T15:16:21Z

The plugin doesn't currently do any logic around checking branch names, so specifying either sonar.branch.name or source.branch.target would result in an error if the project doesn't already exist.

It would be possible to check whether sonar.branch.name equals master and return a DefaultBranchConfiguration instance in that case, providing sonar.branch.target also equals master - or is blank or unspecified - otherwise there are likely to be problems using the branch at a later point.

I don't know how the official version does this so can't tell if we're being consistent, but the documentation seems to indicate the default branch is created as master so this approach should be consistent.

We'd therefore handle combinations of inputs on a 'missing' project in the following way:

sonar.branch.name	sonar.branch.target	Supported
not specified, empty, or master	not specified, empty, or master	✔️ Targets master branch
not specified, empty, or master	anything non-empty and not master	✖️ Throws error with request to scan main branch first
anything non-empty and not master	anything	✖️ Throws error with request to scan main branch first

Does this proposed approach follow what you're attempting @dejangeci?

dejangeci · 2019-03-26T15:54:41Z

@mc1arke Looks good to me.

Second opinion from @winterheart, @nixel2007?

nixel2007 · 2019-03-26T16:29:32Z

Could you get info about project existance before scan? I am a gitflow-guy, so most projects start analyze from develop branch. From table above I'll get an exception on first run

mc1arke · 2019-03-26T16:48:00Z

As per my comments in CommunityBranchConfigurationLoader.java, without deviating from what SonarQube currently has documented (which is what I'm initially aiming for feature parity against), there isn't really a way of using something other than master as the primary given the information available.

It is theoretically possible to identify a new project because the branch list (and therefore the default branch) is empty when the scanner runs, but there's then no idea about whether a user expected the current branch to be the main branch, unless we treat branchList == empty AND sonar.branch.name == sonar.branch.target as the condition for creating the branch as primary. Other than this, it should be possible to introduce a variable that specifies the default primary branch for new projects, or even treat the first submitted branch as the primary, but I don't know how the existing SonarQube branch feature handles this scenario.

SonarQube returns an empty branch list if the project doesn't already exist, which results in an error being thrown telling the user to re-run the scan with no branch parameters set, even if no branch analysis parameters were specified. However, when a project is created through the Web interface, SonarQube automatically creates a default branch named `master` which the scanner picks up as the primary branch and targets if no other parameters are specified. This inconsistency means users can't have SonarQube automatically create projects, but have to use the Web interface to set-up any projects first. To make the setup consistent, the check for no branches existing is extended to also check if any of the branch parameters have also been specified. This way, if no branches exist but no branch parameters were specified then a `DefaultBranchConfiguration` instance is returned which points the analysis at the a default `master` branch which SonarQube will automatically create. Similarly, if no branches exist but a source branch of master is specified then a `DefaultBranchConfiguration` is also returned, providing a target branch either isn't specified or also points at master.

mc1arke · 2019-03-26T22:20:36Z

I've made updates to the previous bugfix branch to meet the specifications in the table above, with the extra caveat that the source branch must be the same as the target branch if the target branch has been specified. This works in my local testing with:

A scan of a non-created with no branch parameters specified - success
A scan of a non-created project with source and target set to master - success
A scan of a non-created project with only target set - expected error
A scan of a non-created project with a non-master source branch specified - expected error
A scan of a new project with source and target set to master - success

It would be nice if someone could build and run this branch locally with some of their own real-world projects to confirm it works as they expect.

@nixel2007 If you would like to target a branch other than master as the default primary then please raise a separate issue, or a pull request.

SonarQube returns an empty branch list if the project doesn't already exist, which results in an error being thrown telling the user to re-run the scan with no branch parameters set, even if no branch analysis parameters were specified. However, when a project is created through the Web interface, SonarQube automatically creates a default branch named `master` which the scanner picks up as the primary branch and targets if no other parameters are specified. This inconsistency means users can't have SonarQube automatically create projects, but have to use the Web interface to set-up any projects first. To make the setup consistent, the check for no branches existing is extended to also check if any of the branch parameters have also been specified. This way, if no branches exist but no branch parameters were specified then a `DefaultBranchConfiguration` instance is returned which points the analysis at the a default `master` branch which SonarQube will automatically create. Similarly, if no branches exist but a source branch of master is specified then a `DefaultBranchConfiguration` is also returned, providing a target branch either isn't specified or also points at master.

mc1arke · 2019-03-27T21:36:33Z

Fix released in version 1.0.1

pdolezal · 2019-08-08T20:28:48Z

Would it be possible to reopen the issue? Our problem resembles the situation that @nixel2007 described for the case of Git Flow, but comes from a different side.

The analysis is triggered by Jenkins pipelines. The pipelines pass the branch name as the properties to SonarQube. And when the project does not exist in SonarQube, the analysis fails, so does the pipeline and the build is broken. Of course, Jenkins can't know whether a project already exists in SonarQube, so it hardly can be blamed.

In our case this becomes a show stopper as everyone can imagine. We have many small repositories, we use Git Flow and our team decided to set up an own SonarQube instance from scratch (since we want to stop sharing a SonarQube instance used by another team). And because we are starting from scratch, we wanted to try the latest LTS, so we gave 7.9.1 a chance.

We used an older SonarQube before (7.6, to be precise). The older version created a project without asking and with no problems, so we were happy. But it is practically unbearable to create the projects manually in the UI. Because of Git Flow, it is not even a one-shot situation, but any new project (which is quite often) requires an annoying manual action. If the plugin created a new project as the older SonarQube version did, we would be happy again.

If it is not possible, we have quite few options, if not counting the unprobable one of getting a better SonarQube edition: either reverting back to the no-fuss older version, or maybe the Jenkins pipeline could attempt to create the project always before the analysis. It seems possible with the Web API. But such a solution looks really awful, doesn't it?

mc1arke · 2019-08-12T10:06:49Z

@pdolezal whilst I agree with you on this, SONAR-11155 is actually the blocker here given I've initially aimed to match the documented SonarQube parameters, and there's options in SonarQube for specifying the default branch name.

If SonarSource don't provide any option for resolving this in the near future then I'm happy to add one to this plugin, but I'm aiming for feature parity rather than additional features in the early releases.

codependent · 2020-05-12T15:07:40Z

@mc1arke I just run into this issue. Apparently this problem was fixed in Sonar 8.0 but even though I'm using 8.3.1 I still get this error when setting -Dsonar.branch.name and running the analysis for a new project:

17:03:23  Caused by: java.lang.IllegalStateException: Unable to load component interface org.sonar.scanner.scan.branch.BranchConfiguration
17:03:23  	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:66)
17:03:23  	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)
17:03:23  	at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:118)
17:03:23  	at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
17:03:23  	at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:78)
17:03:23  	at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:309)
17:03:23  	at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:335)
17:03:23  	at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270)
17:03:23  	at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364)
17:03:23  	at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56)
17:03:23  	at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
17:03:23  	at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
17:03:23  	at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699)
17:03:23  	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647)
17:03:23  	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:64)
17:03:23  	... 219 more
17:03:23  Caused by: No branches currently exist in this project. Please scan the main branch without passing any branch parameters.

qalinn · 2020-07-30T15:28:08Z

@mc1arke Also I have the same issue.
Could you take a look, please?

mc1arke · 2020-07-30T22:13:11Z

This was only fixed in 1.4.0 of the plugin. If you're still facing an issue when using the correct version then you'll need to provide full replication steps.

seven-yu · 2020-08-04T06:59:51Z

@mc1arke Also I have the same issue.

This was only fixed in 1.4.0 of the plugin.
I did not find the sonar version supported by plugin version 1.4，can plugin version 1.4 support sonar version 7.9?

mc1arke · 2020-08-04T07:15:18Z

See https://github.com/mc1arke/sonarqube-community-branch-plugin/releases/tag/1.4.0 - 1.4.0 only supports Sonarqube 8.1.

The change that introduced the ability that allows branches to be created independently is not backwards compatible with 7.9 so cannot be cherry-picked into that release of the plugin.

seven-yu · 2020-08-04T09:03:55Z

See https://github.com/mc1arke/sonarqube-community-branch-plugin/releases/tag/1.4.0 - 1.4.0 only supports Sonarqube 8.1.

The change that introduced the ability that allows branches to be created independently is not backwards compatible with 7.9 so cannot be cherry-picked into that release of the plugin.

thank you

momcilo78 · 2020-10-15T10:05:17Z

@mc1arke sorry for asking on closed issue: but is it possible to use LTS 7.9 with 1.3.2 of the plugin?

genesis-jeff · 2020-10-17T09:13:40Z

@momcilo78 https://github.com/mc1arke/sonarqube-community-branch-plugin#compatibility

mc1arke changed the title ~~mvn sonar:sonar fails with exception when project not created yet in Sonarqube~~ Analysis fails with exception when project not created yet in Sonarqube Mar 25, 2019

mc1arke self-assigned this Mar 27, 2019

mc1arke closed this as completed Mar 27, 2019

nixel2007 mentioned this issue Apr 4, 2019

Does not work on latest 7.7 #5

Closed

mc1arke added the bug Something isn't working label Apr 9, 2019

mc1arke mentioned this issue Sep 10, 2019

Allow an empty project to scan with a long-term branch #32

Closed

dpandolfo mentioned this issue Oct 25, 2019

Upgrade to support sonarqube 8.0 #38

Closed

vdelendik mentioned this issue Dec 16, 2020

migrate to 1.6.0 community branch plugin zebrunner/sonarqube#29

Closed

zbubric mentioned this issue Sep 9, 2022

Sonar 9.4/9.6 and plugin v1.12 issues #666

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Analysis fails with exception when project not created yet in Sonarqube #1

Analysis fails with exception when project not created yet in Sonarqube #1

winterheart commented Mar 25, 2019

mc1arke commented Mar 25, 2019

winterheart commented Mar 25, 2019

dejangeci commented Mar 25, 2019 •

edited

Loading

mc1arke commented Mar 25, 2019

nixel2007 commented Mar 25, 2019

dejangeci commented Mar 26, 2019 •

edited

Loading

mc1arke commented Mar 26, 2019

dejangeci commented Mar 26, 2019

nixel2007 commented Mar 26, 2019

mc1arke commented Mar 26, 2019

mc1arke commented Mar 26, 2019 •

edited

Loading

mc1arke commented Mar 27, 2019

pdolezal commented Aug 8, 2019 •

edited

Loading

mc1arke commented Aug 12, 2019

codependent commented May 12, 2020 •

edited

Loading

qalinn commented Jul 30, 2020

mc1arke commented Jul 30, 2020

seven-yu commented Aug 4, 2020

mc1arke commented Aug 4, 2020

seven-yu commented Aug 4, 2020

momcilo78 commented Oct 15, 2020

genesis-jeff commented Oct 17, 2020

Analysis fails with exception when project not created yet in Sonarqube #1

Analysis fails with exception when project not created yet in Sonarqube #1

Comments

winterheart commented Mar 25, 2019

mc1arke commented Mar 25, 2019

winterheart commented Mar 25, 2019

dejangeci commented Mar 25, 2019 • edited Loading

mc1arke commented Mar 25, 2019

nixel2007 commented Mar 25, 2019

dejangeci commented Mar 26, 2019 • edited Loading

mc1arke commented Mar 26, 2019

dejangeci commented Mar 26, 2019

nixel2007 commented Mar 26, 2019

mc1arke commented Mar 26, 2019

mc1arke commented Mar 26, 2019 • edited Loading

mc1arke commented Mar 27, 2019

pdolezal commented Aug 8, 2019 • edited Loading

mc1arke commented Aug 12, 2019

codependent commented May 12, 2020 • edited Loading

qalinn commented Jul 30, 2020

mc1arke commented Jul 30, 2020

seven-yu commented Aug 4, 2020

mc1arke commented Aug 4, 2020

seven-yu commented Aug 4, 2020

momcilo78 commented Oct 15, 2020

genesis-jeff commented Oct 17, 2020

dejangeci commented Mar 25, 2019 •

edited

Loading

dejangeci commented Mar 26, 2019 •

edited

Loading

mc1arke commented Mar 26, 2019 •

edited

Loading

pdolezal commented Aug 8, 2019 •

edited

Loading

codependent commented May 12, 2020 •

edited

Loading