Cannot read property 'length' of undefined

[roadiehq]

Cannot read property 'length' of undefined

[adamdmharvey]

I wonder if the issue is here:

backstage-plugin-jira/src/api/index.ts

Line 27 in c71a684

const REST_API = 'rest/api/3/'

This endpoint does not exist on Jira Server / Data Center. Even in the latest release, 8.14, it's /rest/api/2. I wonder if /rest/api/3 is only for the Jira Cloud (SaaS) end point.

This is the doco for the rest API in the latest release:

https://docs.atlassian.com/software/jira/docs/api/REST/8.14.0/

And I'm on a slightly older 8.x from earlier this year which only has a /rest/api/2 path.

But the cloud doco has the v3:

https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/

So two fold:

• Better error checking for feedback to either the end-user (browser) or admin (console logging) on failure to get content
• Way to customize the REST_API path, defaulting to the one for cloud but if a user provides it allow it to be overwritten, and we'd want to note in the Doco if you are on Server/Data center products you'd need to add that?

[dtuite]

@adamdmharvey Thanks Adam. We will investigate and come up with a few improvements. We'll keep you updated.

[lewtakm]

I just created a PR: #5, hopeful it will resolve all reported issues.

[lewtakm]

@adamdmharvey I just published new version of the plugin on the NPM (0.2.0). Please try the new version if you could and let me know if it is working.
One small change though, you must configure desired API version (default to 3) in app-config:

jira:
  apiVersion: 2

[adamdmharvey]

This is fantastic, thanks @lewtakm - really appreciate your efforts here.

So far, not able to get the apiVersion config to kick in. Some debugging/troubleshooting:

• Confirmed I'm on v0.2.0
• Added a root jira.apiVersion per doco, doesn't get picked up
• Added a root apiVersion (just in case), doesn't get picked up

You'll see all of my testing is hitting the v3 API URL which I don't have on my Jira Data Center instance:

Now, as a very odd test, I tried resetting the proxy config like so:

 '/jira23/api':
    target: 'https://my-custom-jira-url.mycompany.com'
    headers:

I can see this loading via the Backstage startup:

2020-11-27T05:28:58.482Z proxy info [HPM] Proxy created: [Function: filter]  ->  https://api.newrelic.com/v2
2020-11-27T05:28:58.482Z proxy info [HPM] Proxy rewrite rule created: "^/api/proxy/newrelic/apm/api/" ~> "/"
2020-11-27T05:28:58.482Z proxy info [HPM] Proxy created: [Function: filter]  ->  https://api.buildkite.com/v2/
2020-11-27T05:28:58.483Z proxy info [HPM] Proxy rewrite rule created: "^/api/proxy/buildkite/api/" ~> "/"
2020-11-27T05:28:58.483Z proxy info [HPM] Proxy created: [Function: filter]  ->  https://my-custom-jira-url.mycompany.com
2020-11-27T05:28:58.483Z proxy info [HPM] Proxy rewrite rule created: "^/api/proxy/jira23/api/" ~> "/"

Which means I've successfully registered this proxy path. HOWEVER, it seems the plugin is still using the default proxyPath defined in the code:

2020-11-27T05:29:43.725Z backstage info ::1 - - [27/Nov/2020:05:29:43 +0000] "GET /api/proxy/jira/api//rest/api/3/project/PROJECTKEY HTTP/1.1" 404 - "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36 Edg/87.0.664.41"

So I'd almost wonder - perhaps none of the configuration options are being properly loaded into the plugin at all? Maybe a test case (a la *test.ts) could be valuable to inject different params and make sure the URLs are coming out? I could be off base here but just trying to guess.

Any advice?

THANK YOU AGAIN!

[adamdmharvey]

FYI cloning locally and manually replacing the DEFAULT_REST_API_VERSION with a 2 has fixed it for me temporarily, at least allowing me to further test the plugin and code, but still can't get it to pick up the getConfig("jira.apiVersion") settings.

[adamdmharvey]

I've further tested multiple times, and for the life of me can't get the options to load. I'm pretty confident neither the proxyPath from the actual config nor the apiVersion are being read in. However, the validations all work properly. (e.g., if changing the config schema and running yarn backstage-cli config:check.) A cli config:print properly prints the config, but the current api doesn't seem to collect it. I've tried permutations like putting it under app > jira > apiVersion, or changing the gets to get('jira').getOptionalNumber('apiNumber') and so on, but still haven't figured out what is wrong.

I did find if I hardcode it here:

factory: ({ discoveryApi, configApi }) => {
        return new JiraAPI({
          discoveryApi,
          apiVersion: 2
        });
      }

That works, so it's being passed around, but NOT being collected from the config API call.

[lewtakm]

@adamdmharvey can you tell me if are able to read any others data from config?

For example if you put console.log like this:

Your config is printed correctly on the console?

[adamdmharvey]

@lewtakm Interestingly, no. With the log on, tried both in app-config.local.yaml as well as app-config.yaml, and no luck. It never seems to be registered as a root object.

Tried a few different placements in the location of the file as well. Assume it works for you?

[lewtakm]

@adamdmharvey yes it works. My last thought can you confirm that you have configSchema in package.json file of the plugin?

[adamdmharvey]

Yep, it's definitely in there:

[adamdmharvey]

Going to mark this one closed!

Re this thread:
https://discord.com/channels/687207715902193673/687235481154617364/783140832479412245

I had git cloned this repo, put it in my plugins/ folder, and ran yarn in my monorepo package but never did a yarn add. This allowed me to test your code locally. BUT, it seems like the config loader validates folders in the monorepo using a 3rd party learna library, and I'm taking a wild guess that the library doesn't like the local linkage! Anyway, I wiped out my local code, went back to your published NPM code, did a valid yarn add to add your package, and now the config it works like a charm.

So maybe I'll report a bug in Backstage itself.

Thanks Mateusz!