backstage: catalog-import plugin does not support Unicode characters in catalog-info.yaml file

Expected Behavior

Importing a GitHub repo should allow Unicode characters in the submitted catalog-info.yaml file. For example, a file like this should work:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: test-service
  description: Description with emojis 🤖
spec:
  lifecycle: production
  type: service
  owner: test-team

Current Behavior

Right now if you try to import the file above, you will get the following error: Failed to submit PR to repo, Failed to execute 'btoa' on 'Window': The string to be encoded contains characters outside of the Latin1 range.

Possible Solution

Use a library like js-base64 to encode the file contents, which allows for Unicode characters.

Steps to Reproduce

Create a custom LocationAnalyzer
Modify the generated Entity in the custom LocationAnalyzer by adding a description field with Unicode characters in it
Use custom LocationAnalyzer
Try to import GitHub repository via /catalog-import

Context

We are trying to add some extra information to the generated catalog-info.yaml file. This reduces the work for developers as they can import the file and not make any modifications afterwards. We fetch the description from GitHub and add it to the generated catalog-info.yaml file. Some of our repos have emojis in them, so creating the PR fails due to the lack of Unicode support in the native btoa function.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 2
Comments: 21 (15 by maintainers)

Commits related to this issue

Merge pull request #5146 from padraigobrien/gh-4276-handle-non-latin-characters Enable non unicode character in catalog import. — committed to backstage/backstage by jhaals 3 years ago

Most upvoted comments

I am happy to wait, I can be working on the issue quietly in the background and implement once #4271 is merged

padraigobrien on Jan 28, 2021

Should be fixed with #5146, thanks @padraigobrien.

Fox32 on Apr 7, 2021

Fixed by #5146

padraigobrien on Mar 26, 2021

Thanks, Tyler. I can reproduce this now. I will start working on it

padraigobrien on Mar 22, 2021

I will note, that this isn’t a big blocker. We don’t have too many repos that fall under this case. You can technically work around this by manually creating the catalog-info.yaml file and then importing it. However, it seems reasonable that this should be possible either way.

andrewthauer on Mar 17, 2021

@adamdmharvey - @tylermarien and I work together so I’ll do my best to explain 😃

The catalog-import makes a backend call to the /api/catalog/analyze-location route. By default the catalog-backend is setup to use the RepoLocationAnalyzer as a template which the catalog-import then uses for the entity spec. However, you can actually swap out the implementation (in packages/backend/src/plugins/catalog.ts) which is what we’ve done. Ours makes a GitHub API call to get the repo metdata. It pre-populates the metadata.description based on the repo description. So basically the /analyze-location route just passes back the description with an emojii to the catalog-import front-end plugin. The plugin actually makes the requests to the GH API. So it seems like an issue on the front-end.

I suspect, if the description was editable in the UI, you could probably get the same result by adding an emojii or other unicode characters. Hope that helps clarify things.

andrewthauer on Mar 17, 2021