Entity Registration cannot process branches with forward slash

[brizzbuzz]

Expected Behavior

When testing out registering a service in backstage, say on a feature branch feature/my-awesome-feature, the user should be able to register by passing https://github.com/MyOrg/my-service/blob/feature/my-awesome-feature/catalog-info.yaml to the entity registration form

Current Behavior

Instead, the user will get the following error

Unable to read url, NotFoundError: https://github.com/MyOrg/my-service/blob/feature/my-awesome-feature/catalog-info.yaml could not be read as https://api.github.com/repos/MyOrg/my-service/contents/backstage/catalog-info.yaml?ref=feature, 404 Not Found

my-awesome-feature looks as though it is being truncated from ?ref=...

Possible Solution

Haven't looked into it, but presumably a simple fix of just not truncating, and perhaps URL encoding the /?

Steps to Reproduce

1. Create a branch with a / in the name
2. Attempt to register an entity on that branch in Backstage

Context

Honestly, not a blocker, since 99/100 you are either going to have the entity registered on a scaffolding event or are going to track the head branch, but for testing this can be a bit of a rough start for people trying to be onboarded to backstage.

Your Environment

• NodeJS Version (v12): 12
• Operating System and Version (e.g. Ubuntu 14.04): Mac (though deployed app is running ubuntu.... 18?)
• Browser Information: Chrome

[adamdmharvey]

Related, though potentially not exactly the same:
#2815

[benjdlambert]

@rgbrizzlehizzle yep we're aware of this, and it's a little tricky to solve as without making a call out to the required git provider we don't know what is a branch name and what is a file path. More info can be found in the ticket @adamdmharvey mentioned and more in this one too IonicaBizau/git-url-parse#114 (comment)

It's not impossible, just needs some more thought on how we do this I think.

[kuangp]

Wanted to add that we're also hitting this limitation to keep this issue relevant since #2815 was closed as stale.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kiranpatel11]

We are also getting this for Bitbucket Server (on-prem) while registering resource from non-default branch.

URL: https://mybitbucket-server.company.com/projects/BS/repos/backstage/browse/catalog-info.yaml?at=docs/readme

This URL was not recognized as a valid GitHub URL because there was no configured integration that matched the given host name. You could try to paste the full URL to a catalog-info.yaml file instead.

[benjdlambert]

@kiranpatel11 I don't think that yours is the same issue. I think it's down to the support in the catalog-import route for anything that is not Github, or Github Enterprise.

It doesn't seem to really support much other than that at the moment - but contributions are welcome 🙏

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kuangp]

unfortunately, still relevant :(

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[freben]

Keeping this alive.

One proposed way forward is to support alternative URL formats, as seen in some other tools. For example, something along the lines of github://github.com?ref=branch%2Fwith%2Fslash&org=backstage&owner=backstage&path=%2Fcatalog-info.yaml or so.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[freben]

Keeping alive again. Still interested in alternative url formats - and this should probably be backed by a parseUrl method in ScmIntegrationRegistry and the respective integrations under it. It would have special case support for one or more custom formats, plus falling back to the git-url-parse that we know and hesitantly love.

[dallasgutauckis]

I'll help keep this issue alive as well to lengthen the stale-check time. I just ran into this at SeatGeek, where my branching pattern also uses a forward-slash on a gitlab instance. I did also figure out the uri-encoding (/ -> %2F) of the slash workaround before jumping over here to look for this issue :-)

[freben]

Thanks. I started experimenting briefly on what a centralized parsing facility might look like, which would add support for alternative formats and might be a place to put per-provider special knowledge. But didn't get all that far.

[ShayNehmad-RecoLabs]

OMG, just found this issue, it killed my last... 3 hours?

Worth fixing 😢

[zcstellar]

Would love at least a note in the docs about this. I also just lost a couple hours wondering what was going on :(

[Rugvip]

Gonna close this as a duplicate of #2815, let's focus the discussion there.