[🙏] Use backstage.io/source-location instead of github.com/project-slug or snyk.io/target-id

[emilkvarnhammar]

Describe the user need
I've tested the 2.0.0 version of the plugin, and I think it's an improvement that we no longer have to specify project-ids manually in catalog-info.yaml.
But, I think it should be possible to make use of backstage.io/source-location rather than having to specify the project-slug. With the current behavior, we have to make sure that project-slug is updated if a repo is renamed.

Describe expected behaviour
Derive the "<owner>/<repo>" from backstage.io/source-location, when resolving the Snyk targets of a specific Github repo. If support for github.com/project-slug is kept for backwards compatibility, add a snyk.io feature flag to ignore it.

Additional context
Key motivation, lifecycle aspects of relationships between repos and Snyk projects: We currently handle renamed repos with snyk-api-import, to ensure that they are re-added to Snyk - and removing the orphan Snyk project referring to the old repo name. If the plugin honors project-slug, it will still refer to the orphan project (which will not contain the current vulns data). We'd like a unified relationship between Snyk and Github, in all contexts; Snyk UI, Github PRs, Backstage plugin and use snyk-api-import to update when needed.

[jen13501]

I'd also like to see this, we don't use github and are therefore not using the github.com/project-slug annotation.

[aarlaud]

Hi there, thank you for the feedback.

I knew that the project-slug being github specific was not going to fly for lots of people, which is why I added the target id option.

While I agree with the source location annotations being more generic and nicer to use overall, I have a main issue with it, which is reliably deriving the owner/repo (or equivalent) across all the SCMs we support. It is not something I chose to get into at this time because of the variety of url patterns we've seen to date.
Extracting reliably the target name, which also means understanding when we are not extracting the right thing to then bail and require a target id instead, is not something I've dug into. It'll require some research around how we do that for naming targets on our backend so the plugin can mimick this process reliably.

@jen13501 what SCM are you using?

[jen13501]

We are using Bitbucket and Gitlab. I ended up writing a custom processor to get the target id from the source location annotation but to your point, I had to make some assumptions about what the target's display name was going to be because we are importing projects into Snyk in a few different ways. I have no idea if it would work for other teams.