Update issueDashURL to contain correct revision branch

[JeffreyHuynh1]

Overview

fossa test reports the issue URLs incorrectly. It points to the master branch even when last analysis was performed on a different branch.

Acceptance criteria

issueDashURL should contain the correct branch.

Testing plan

To view current state of our issue urls in fossa test

• fossa analyze /path/to/project/ a project on a branch that is NOT master
• fossa test /path/to/project/
• You will see that the issueDashURL will contain /refs/branch/master

To view updated issue urls

• git checkout fix-issueUrl
• fossa test /path/to/project/

Risks

I have decided to update the issueDashURL in the CLI rather than in Core's /api/cli/:locator/issues endpoint for the following reasons:

• There is no way to generate the issueDashURL with the correct branch in the /api/cli/:locator/issues endpoint without breaking backwards compatibility.
  • Updating the API to accept the project's branch would be necessary to ensure all users generate URLs with correct branch info. Without explicitly passing the project's branch to the API, it would be impossible to associate a revision's scan with the correct branch.

Metrics

References

ANE-1771

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

[zlav]

This PR looks good, but I'm concerned about the assumption that we can get the branch information locally from the user's machine and use that to expect the URL exists within FOSSA. The reason I say this is because we're using projectBranch revision which is what the CLI is submitting to Core, and then we are modifying the response URL from Core to include the branch that we found locally.

This feels brittle to me. I buy your reasoning about being backwards compatible in Core, but I do think that core is the correct place to fix this. I'm open to hearing otherwise.

My only other idea that doesn't break backwards compatibility is to return 1 branch associated with the revision, since that is strictly more likely to be accurate than returning master. (Partially because we don't support linear git history, so must revisions only belong to 1 branch)

Another idea would be to validate that the branch, revision, and URL are correct by making some other API call to core.

[zlav]

Can you add a specific example of before and after? I think this is close, but just write out something like /refs/branch/differentbranch

[JeffreyHuynh1]

Making the changes for correct issue dash url in Core. Here's the pr: https://github.com/fossas/FOSSA/pull/12973