The report files are empty when we couldn't resolve the full name for a repo about macaron

[tromai]

After looking through it. It looks like that we have long been assuming that the repositories we analyzes in Macaron has a valid remote origin url (i.e all the repositories are cloned from a remote URL) even when we are analyzing a local repository.
However, this isn't usually the case as we have discovered that we can clone from a local repository or clone from a git bundle. In these cases, the origin remote of those repositories will not have a remote URL (e.g https://...).
For example, given a file.bundle at /tmp/bundle/file.bundle, when we run cd /tmp/repo/ && git clone ../bundle/file.bundle the repository will be cloned to /tmp/repo/file. When we run git remote get-url origin inside the return value is /tmp/bundle/file.bundle. In these cases, Macaron won't be able to process and extract git services, full name (org/name) out of it.
Therefore, to address this issue, we need to look into these aspects:

• How we can support a local repository with origin being a local path.
• Make sure that we could get the format org/name for the directory where the report files are stored. The full name could be made up of local_repos and the basename from that local path. For example: the reports for /tmp/bundle/file.bundle would be stored in output/reports/local_repos/file.bundle.
• This would also indirectly affect this part, where we shouldn't try to assume that the origin remote path must always a remote URL.
  • I think we need to implement a better way to come up with a unique ID for each target repository in the analysis.
  • Another aspect that I have observed is that the way we distinguish duplicated Records is by using the remote path of the repository only. When we come up with a better unique ID solution for each target repository, we need to changes this mechanism too. One challenge I can see at the moment is that the duplicated records only have the config values (which mean we might not have branch, digest values ready - i.e this part). I think at the moment, we don't have the way to obtain the exact digest for a target repo from the dependencies found from the dependency solver anyway. I need to think more about this.