Hey @nkojuharov, thanks for reporting this. I think you just found a bug.
To confirm, could you please run this SQL query on your database, and tell us if the query returns any rows? I don’t need you to post the result here, I only need to know if the query found any results.
SQL
select loc_grouped_branches.projectUuid,
loc_grouped_branches.projectName,
loc_grouped_branches.projectKey,
loc_grouped_branches.ncloc as loc,
p.ncloc
from (
select pb.project_uuid as projectUuid,
p.name as projectName,
p.kee as projectKey,
pb.kee as branchName,
pb.branch_type as branchType,
lm.value as ncloc,
row_number() over (partition by pb.project_uuid order by lm.value desc, pb.uuid asc) row_number
from live_measures lm
inner join project_branches pb on pb.uuid = lm.component_uuid
inner join projects p on p.uuid = pb.project_uuid
where lm.metric_uuid = (select uuid from metrics m where name = 'ncloc')
and p.qualifier ='TRK'
) loc_grouped_branches
inner join projects p on p.uuid = loc_grouped_branches.projectUuid
where loc_grouped_branches.row_number = 1
and loc_grouped_branches.ncloc != p.ncloc
order by loc_grouped_branches.ncloc desc
If this returns any result, it means that some branches from your projects were deleted (manually, or through an automatic purge for inactivity), and the “new” LOC score for the project was not correctly updated after the purge. If my assumption is correct, if you compute the sum of diff between the loc
and ncloc
columns, you will find the same gap you already noticed between SQ UI and api/projects/license_usage.
In this case, as a workaround, you can re-analyze any branches from the projects found in the query: the new analysis will fix the LOC count for the project.