[FOLIO-3641] New projects not automatically added to Sonarqube Created: 14/Nov/22  Updated: 20/Apr/23

Status: In Progress
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P2
Reporter: John Malconian Assignee: John Malconian
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint: DevOps Sprint 159, DevOps Sprint 160, DevOps Sprint 152, DevOps Sprint 154, DevOps Sprint 155, DevOps Sprint 157, DevOps Sprint 158
Development Team: FOLIO DevOps
RCA Group: TBD

 Description   

Normally, new projects/repos are automatically added to SonarCloud when the CI workflow is initially enabled and run on the default main/master branch of the repo. However, this has stopped working at some point. Now, initial configuration of the project needs to be manually enabled in SonarCloud before scans initiated from CI are performed. This behavior has been confirmed with several recent UI-based projects that use Github Actions.



 Comments   
Comment by John Malconian [ 14/Nov/22 ]

CI configures a SQ project key in the following format 'org.folio:REPO_NAME'. However, I've noticed when initially configuring a project manually in SonarCloud, the project key format is 'folio-org_REPO_NAME'. After initial configuration, I change the project key to org.folio:REPO_NAME and SQ scans work from CI. I also see in the SonarCloud settings for folio-org, under Administration->Organization Settings that the project key for the organization is set to 'folio-org'. It also states that "Organization key must start with a lowercase letter or number, followed by lowercase letters, numbers or hyphens, and must end with a letter or number. Maximum length: 255 characters." I see nothing about ':', so I wonder if this is a recent change. If so, we could try updating the CI pipelines to use the 'folio_org_' prefix for project keys.

Comment by John Malconian [ 14/Nov/22 ]

mod-bulk-operations looks like a relatively new backend module and it has a project key in the org.folio:REPO_NAME format. Assuming this project wasn't manually configured in SonarCloud, one could probably conclude that the project key format is not the problem.

Comment by John Malconian [ 14/Nov/22 ]

Perhaps the default Github branch has something to do with this. Are default branches that a not named 'master' a problem? The folio-org/stripes-ui repo's default branch is 'main'. The error from SQ was "Could not find a default branch to fall back". Of course, I never verified that this error actually occurred on any of the finc UI modules which I recently added to SonarCloud which all gave 'master' as the default branch. Should have tested those repositories to see if they had failed in the same way.

Comment by Ethan Freestone [ 18/Nov/22 ]

I have also encountered this in ui-service-interaction. The default branch there is named `master`, however.

Comment by John Malconian [ 18/Nov/22 ]

So it doesn't appear the issue has to do with the default branch name or project key prefix. I tried a 'folio-org_' prefix and the scan of the master branch still failed with the same error:

INFO: Detected project binding: NONEXISTENT
ERROR: Could not find a default branch to fall back on.

I'm getting the feeling from various hints here and there that an initial scan of the main/master branches from CI will no longer automatically create the project on the SonarCloud side and that the project needs to be manually created first.

Comment by David Crossley [ 10/Jan/23 ]

I, for one, did not do anything special for mod-bulk-operations.

Two recent new back-end repositories had no such problem (mod-settings and mod-di-converter-storage).

So perhaps it is related to new front-end (GitHub Actions Workflows) repos.

Cc: Ankita Sen

Comment by John Malconian [ 10/Jan/23 ]

Right, David Crossley. I think this issue is specific to UI workflows using Github Actions.

Comment by David Crossley [ 20/Apr/23 ]

Some further discussion and investigation at Slack thread #devops 2023-04-19

Generated at Thu Feb 08 23:29:37 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.