Implement ScmProvider.forkDate()

[rafaelbdacosta]

SonarQube 8.4 has added support to use a reference branch for New Code. That requires ScmProvider.forkDate() to be implemented, as discussed at https://community.sonarsource.com/t/compute-new-code-for-branches-using-master-as-reference-on-tfvc/47439.

[lg2de]

Could you please explain a little bit more what is the expectation/use case?
Branches in TFVC a long living branches. Providing the "fork date" for a branch, the time range for "new code" will always increase. All code on the branch will be treat as new code. Is this what you expect?

[anadriewen60]

Hello,
I have the same problem with SonarQube 8.9.2.
What do you mean with 'all code on the branch will be treat as new code' ? what I need is to get the issues that have been added to the code after the date of the reference branch.

[lg2de]

I guess you are using the TFVC branches as feature branches, means short to mid living branches. This is unusual according to my experience. But ok.
We can try whether and how to get the data from the TFVC api. This is some kind of research.
I'll mark it as feature (enhancement).
You are welcome to contribute.

[anadriewen60]

I guess you are using the TFVC branches as feature branches, means short to mid living branches. This is unusual according to my experience. But ok.
We can try whether and how to get the data from the TFVC api. This is some kind of research.
I'll mark it as feature (enhancement).
You are welcome to contribute.

I'm not talking about TFVC branches but SonarQube branches. I mean a SQ branch is not related to a TFVC branch. We create a branch on SonarQube that doesn't exist on TFVC. I don't know if this can be a problem.
Where I work there are teams that are using SonarQube long branches to store the results of the analysis of the build that we release to the customers. For quality reasons we need to keep those results forever :( and every time we release something we need to compare the results with the version that was previously released to the customer.
thanks
I

[lg2de]

I'm not talking about TFVC branches but SonarQube branches.

But the forkDate is related to the TFVC branch, isn't it?

[anadriewen60]

I don't know, I ask the SonarQube support for this. I suspect that this the real issue...

[rafaelbdacosta]

what I need is to get the issues that have been added to the code after the date of the reference branch.

This is what I expect on my case, where I use a feature branch for short development. I want to be able to spot new code smells (when comparing to my integration branch) while development is undergoing, and before they are integrated.

But the forkDate is related to the TFVC branch, isn't it?

That's my understanding.

[anadriewen60]

yes, the forkDate is related to the TFVC branch, I had a look to the ScmProvider documentation

[cfahrenholz]

Hi, it seems we also have the same issue. Our branch scenario is like that in Sonarqube Version 8.9 (build 43852):
We have a “Main” branch from which we build our releases. This branch exists in TFVC and in Sonarqube. We have another branch derived from Main on which the features for the next version are being developed. This branch also exists for TFVC and Sonarqube. During development on feature branch it may be possible some bug fixes on the Main branch occurred in the mean time, which means these fixes will be forward merged into the feature branch.
The New Code of the features branch shall show the differences between Main and feature branch.

Do you plan to implement this?

Thank you for your time and efforts!

[lg2de]

No, I do not plan to implement this.
You are welcome to contribute!
I'll take care on the code review and some regression testing.