Renovate: Refactor global.appMode to support app tokens

[rarkins]

Currently global.appMode is used in a few places within the code to change behavior subtly if Renovate is running as a GitHub app. We should make this a first-class concept so that it's possible to supply an app-generated token for GitHub from the CLI.

[rarkins]

• [ ] 1. GitHub presets fetch code dynamically sets the accept header based on global.appMode. If it used util/http/github then that should handle it for it.
• [ ] 2. gomod artifacts code checks whether to use x-access-token in the git config line
• [ ] 3. platform/github.initRepo() sets the auth differently depending on app or not
• [ ] 4. util/http/github manipulates the accept header depending on the mode
• [ ] 5. Master Issue only adds a manual job checkbox if in app mode
• [ ] 6. GitHub doesn't allow /user API access when using an app token, as mentioned in https://github.com/renovatebot/config-help/issues/669

[rarkins]

I can think of two obvious choices for how to implement this:

• Make appMode an admin option in config, instead of a global, or
• Specify that token should be specified as x-access-token:{token} to implicitly trigger app mode

The second option would mean that a few of the above will no longer need "app awareness" because the token won't need massaging anymore.

In either case our accept header should be dynamically set using hostRules (we may need to improve our headers merging logic so that it's a deep merge instead of shallow.

So:

1. Remove this logic and use util/http/github instead
   2&3. Remove the logic as the token will already have the prefix
2. Replace with a hostRules entry + deep headers merging
3. This maybe shouldn't be limited to the app anyway
4. Ideally we should avoid doing this query altogether, but I'm not sure the best way yet

Additionally:

1. Our util/http token inserting code needs to be updated to strip x-access-token: from the value put into the Authorization header

[viceice]

related to #3376

[rarkins]

More pieces: we use a GraphQL query to fetch "our" issues, and for that we need to know our username. e.g. it is renovate[bot] for the official app. I guess we could reuse the username field for this and make it mandatory is an app token is provided. We similarly will need the gitAuthor value to be provided in config if it is not detectable using the /user endpoint.

[dominguezcelada]

More pieces: we use a GraphQL query to fetch "our" issues, and for that we need to know our username. e.g. it is renovate[bot] for the official app. I guess we could reuse the username field for this and make it mandatory is an app token is provided. We similarly will need the gitAuthor value to be provided in config if it is not detectable using the /user endpoint.

I would be happy to collaborate on this but I did not participate on the repo before. Woult it be ok if I draft PR somethig of this?

Thanks

[viceice]

sure, feel free to open a pr.

[rarkins]

@dominguezcelada see #6454 6454

[renovate-release]

:tada: This issue has been resolved in version 22.18.0 :tada:

The release is available on:

• GitHub release
• 22.18.0

Your semantic-release bot :package::rocket: