[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 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 |