Want to rename a project, then start over

SonarQube Server / Community Build
1

Following an upgrade to 8.6, we want to “start fresh” on some projects. That is, we want to start analyzing a project with all new profiles and such, without the history of old issues. In other words, the next analysis should be treated as the first scan, with all issues newly created at that time. But we still want to view issue counts from before this change. So what we want to do is rename the existing project, to “get it out of the way” while still being able to view its history, then “start over” with the project using the original name and key.

So, for instance, we have a project named foobar with key foo:bar. I tried the following:

  1. Change the key of the project to foo:bar_Archive
  2. Run a Maven build with … sonar:sonar ‘-Dsonar.projectKey=foo:bar_Archive’ ‘-Dsonar.projectName=foobar_Archive’ …

This seems to be the steps necessary to rename a project, from what I’ve been able to find online, as it seems one can’t change the name in SQ directly. Sure enough, I can go to the projects list and find the latest analysis under name foobar_Archive, so this seemed to work.

But does SQ retain knowledge of the original name and key? I figured that I had renamed the project, and therefore the old name and key were “free” and a new build would be “starting from scratch.” But when I tried running a new build and scan on Jenkins using the original name and key, I got a failure in the SQ analysis (Jenkins completed OK; the failure was in the SQ project analysis). The web portal didn’t say much besides failure, but I found some messages in …\logs\ce.2021-03-15.log that seem to indicate some kind of a key clash:

Caused by: org.apache.ibatis.exceptions.PersistenceException:
### Error updating database. Cause: com.microsoft.sqlserver.jdbc.SQLServerException: Cannot insert duplicate key row in object ‘dbo.components’ with unique index ‘projects_kee’. The duplicate key value is …

The key value in this case is a path in the project’s filesystem.

So, is there some additional step I need to do to get rid of all traces of the old name while still retaining the old material under a different name?

2

Hi,

I think this is going to be about the keys of sub-project-level items, such as modules. You should be able to tell from the redacted part of the error message.

And in general, yes. Your outlined methodology is sound. But it’s possible that for a more complex structure you may need to make temporary updates to your module poms to override those keys as well…(?)

 
Ann

3

Thanks. This morning I tried this (with a different project) but skipping step 2 (Maven build with the new project key and a new project name). This time, a new build using the original key/name pair works. There are two projects with the same name, but that’s OK since the archived one will have an older date. The projects have the same pom structure so I don’t think that explains why one failed and the other succeeded. But I’ll keep your observations in mind if I encounter this again.

1 Like