Architecture Decision Records :

[kevindubbity]

Plugin Name

Architecture Decision Records

📜 Description

1. Relative links give 403 on github discovery.
2. Details: a. Github Integration correctly configured with Github App: (this configuration pulls entity content just fine for the software catalog) b. Github provider reads a catalog-info.yaml file correctly from github c. catalog-info.yaml contains:

    apiVersion: backstage.io/v1alpha1
    kind: Domain
    metadata:
      name: integrations.gateway.architecture.decisionrecords
      title: Integrations Gateway Architecture Decision Records
      description: These are architecture decision records sourced locally and relative to a single cataloged entity
      annotations:
        backstage.io/adr-location: ./adrs/oas
    spec:
      owner: integrations.gateway

d. The above domain entity loads just fine in backstage.
e.  I have all of the implemented back and front end plugins for Architectural Decision Records correctly (public github repository folders pull ADR content MD files just fine)

👍 Expected behavior

Github App Integrations pulling entity yaml files should be able to get HTTP 200 responses with markdown file contents pulled in using the same backstage.io/adr-location annotation convention as public repositories

👎 Actual Behavior with Screenshots

The call to retrieve the ADR content with relative links fails with a 403 even though the URL is correct when Github App Integrations are used. Public repositories don't have the same problem

👟 Reproduction steps

a. Github Integration correctly configured with Github App: (this configuration pulls entity content just fine for the software catalog) b. Github provider reads a catalog-info.yaml file correctly from github c. catalog-info.yaml contains:

apiVersion: backstage.io/v1alpha1
kind: Domain
metadata:
  name: integrations.gateway.architecture.decisionrecords
  title: Integrations Gateway Architecture Decision Records
  description: These are architecture decision records sourced locally and relative to a single cataloged entity
  annotations:
    backstage.io/adr-location: ./adrs/oas
spec:
  owner: integrations.gateway

d. The above domain entity loads just fine in backstage. e. I have all of the implemented back and front end plugins for Architectural Decision Records correctly (public github repository folders pull ADR content MD files just fine)

📃 Provide the context for the Bug.

No response

👀 Have you spent some time to check if this bug has been raised before?

• [X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [X] I have read the Code of Conduct

Are you willing to submit PR?

No, but I'm happy to collaborate on a PR with someone else

[kevindubbity]

FYI the above yaml content didn't indent properly, but my implementation is correctly formatted and tab spaced.

[vinzscam]

Have you installed the app in your organization?

[kevindubbity]

@vinzscam I'm confused by your question. At present, I am running the codebase locally on a dev machine. I am not sure why having it hosted would make any difference. Can you tell me more?

[awanlin]

@kuangp any ideas on this one?

[kuangp]

hmm can you confirm you have your GitHub App permissions enabled correctly as described here: https://backstage.io/docs/integrations/github/github-apps/#app-permissions

[kevindubbity]

Yes, as I am able to pull in the entities yaml files just fine using the same github app integration configuration.

[kuangp]

Just to confirm:

• you have the Commit statuses: Read-only permission enabled for the GitHub App
• the app is installed on the target GitHub org and target repository

and to collect more info, can you share what version of Backstage/ADR plugin you have installed and what your app-config.yaml integration config looks like (secrets redacted of course)?

[kevindubbity]

Guys I'm so sorry for having wasted your time. The problem was 100% missing the Commit statuses: Read-only permission. I'll try to make it up to you by finding a way to contribute to this plugin. Maybe adding mermaid rendering support to it.

[kuangp]

no worries! glad we were able to figure it out 🙂