feat(bitbucket): main branch status for mend app dashboard

[setchy]

Changes

Adds a new optional configuration, bbMendAppDashboardCheck which provides a convenient way to quick-launch the Renovate Dashboard for a repository for users of the Mend App on Bitbucket.

When set, a successful branch status check will be recorded on the repository's main branch, hyperlinking to that repository's Mend Renovate Dashboard page

Context

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[setchy]

Of course, a Bitbucket Forge App that adds Renovate as a repository left-hand navigation menu would be preferable, but this is may be a sufficient solution in the near-term

[setchy]

I note that the marketplace listing calls this Mend App. Will happily rename the above config option and status name/description to best fit

[rarkins]

Which of these would you expect?

• Turn it on by default, almost nobody would want it off
• Turn it on by default, but in some scenarios users will want it off
• Turn it off by default, users will need to opt-in

[setchy]

Which of these would you expect?

• Turn it on by default, almost nobody would want it off
• Turn it on by default, but in some scenarios users will want it off
• Turn it off by default, users will need to opt-in

Turn it on by default for Mend App users. I assume you have the ability to control defaults for the managed apps?

[rarkins]

We would want to cache the SHA between runs to avoid setting it unnecessarily on future runs. Renovate already ties the repo extract results to defaultBranchSha, so it would be similar to that.

Also, this is in repo config but is done in initRepo() which occurs before repo config is read

[setchy]

I'm not 100% following the ask. I've refactored it to use HEAD so that there isn't a need to resolve or keep track of a SHA.

[rarkins]

Your approach will still use one API call per repo per run, even if the head SHA is unchanged. I would like to leverage the repo cache so that we use an API call only when the default branch SHA has changed.

[setchy]

Leveraged this existing function, which if I understand internally caches the results @rarkins

[rarkins]

Will it cache across runs? I didn't think it did

[setchy]

I'm not 100% certain, but i think it does... testing locally I was using pnpm cache-clean in order to test first-time behavior

[rarkins]

To clarify, is this the goal?

• If default branch SHA has changed since previous run, set a Renovate Dependency Dashboard check
• If default branch SHA hasn't changed, do no API calls (rely on cache to know)

[setchy]

Correct, yes.