Screwdriver: PRs from unknown users throw errors

[stjohnjohnson]

What happened:

• New user created a PR
• No build was created
• API had an error

[sd-api-5b5d5cc74f-92vw2] 180531/210626.338, (1527800786332:sd-api-5b5d5cc74f-92vw2:27:jhv13r8u:10299) [request,webhook,7aac53c0-6516-11e8-8ce5-f7cb536c8940] data: Received event type pr
[sd-api-5b5d5cc74f-92vw2] 180531/210626.374, (1527800786332:sd-api-5b5d5cc74f-92vw2:27:jhv13r8u:10299) [request,server,error] data: TypeError: Cannot read property 'unsealToken' of null
[sd-api-5b5d5cc74f-92vw2] at userFactory.get.then.buildBotUser (/usr/src/app/node_modules/screwdriver-api/plugins/webhooks/index.js:225:56)
[sd-api-5b5d5cc74f-92vw2] at <anonymous>
[sd-api-5b5d5cc74f-92vw2] 180531/210626.332, [response,api,webhook] http://localhost: post /v4/webhooks {} 500 (43ms)

What you expected to happen:
A PR to be opened and executed

Versions:
[email protected]

[Filbird]

Should we allow PR builds to be created/executed for unregistered users? @jithin1987

Currently, if a sync is performed after an unregistered user registers (after making a PR) the PR in question will be created and executed.

[jithine]

Should we allow PR builds to be created/executed for unregistered users?

It should work. We should not error out just because we haven't seen the user before.

[d2lam]

How would we solve this? If the user hasn't gone through login before, he/she hasn't granted access to Screwdriver.

[stjohnjohnson]

@d2lam I'm not sure why a user has to have used Screwdriver for their PR to work. What do we need to use from that user? We should be using the admin token from the pipeline, no?

[catto]

@stjohnjohnson I guess that you need to login to your screwdriver cluster with your git headless user.
https://github.com/screwdriver-cd/screwdriver/blob/master/config/default.yaml#L175

If committer of each PR does not exist in screwdriver, it tries to use git headless user (buildBotUser).
https://github.com/screwdriver-cd/screwdriver/blob/master/plugins/webhooks/index.js#L224-L225

It seems that this behavior is not documented yet. We have to add a document for that even if this could not help.