[Bitbucket Self Hosted] Onboarding New Option Suggestion

[jerome-nelson]

Current Issue

Bitbucket Cloud PRs cannot be deleted only declined. In this state it's not possible to rename the PR. The only solutions I can think of are to:

1. Switch off onboarding and manually add - which breaks the automated workflow
2. Use onboardingBranch or branchPrefix to re-trigger, but same issue as above.

Suggestion
Add Config Option like forceOnboarding - default false. This would override any onboarding re-trigger conditions if set. Renovate wouldn't need to care about any cloud specific changes relating to PR functionality as well.

Current Options

Declined State

Thanks for reading :-)

[rarkins]

See #10674 for one option

[jerome-nelson]

Thanks for the quick answer :-). It still doesn't seem to apply to Bitbucket Cloud.

(Originally I missed this code)
https://github.com/renovatebot/renovate/blob/main/lib/platform/bitbucket/index.ts#L651 (But it seems like you are already aware of this).

---

I believe in delegating this responsibility to developers - hence the `forceOnboarding: false` . Alternatively we could check for declined onboarding PRs and check the decline message. If this message is `renovate-ignore` then it can be recreated.

I also believe the issue occurs because of matchState and the PrState type not having platform specific implementations

renovate/lib/platform/bitbucket/index.ts

Line 200 in 569bee6

function matchesState(state: string, desiredState: string): boolean {

---

API
It seems that we are returning - which returns a list of ALL PR States
https://api.bitbucket.org/2.0/repositories/{repo}/pullrequests?state=

What should be requested is:
https://api.bitbucket.org/2.0/repositories/{repo}/pullrequests?state=DECLINED

It is also possible to set a "reason" message on declined PR - this could be set to renovate-ignore and then caught by renovate - in order to stay in line with the Azure fix.

Screenshots
API Return Reference

DEBUG Logging Issues

[jerome-nelson]

Understood - but in BB Cloud, when you decline a PR, it becomes immutable. Instead of // renovate-ignore approach, how about simply checking if BB PR is in declined state?
Once declined it cannot be re-opened

[rarkins]

People usually decline PRs because they want them ignored, not because they want another one created.

Can you describe again what your use case is? e.g. You have an onboarding PR which you edited and now you want to start over?

[jerome-nelson]

Sure no problem :-) hope this makes it clearer

Use Case
A user accidentally declines a PR on BB Cloud, not knowing that this Onboarding PR cannot be recreated. The message on the PR doesn't take into account that Bitbucket PRs are not change-able once declined.

---

I simply made a mistake, whilst testing. I was new to Renovate and when I look at https://docs.renovatebot.com/getting-started/installing-onboarding/ it doesn't mention anything about Declined PRs.

If I want to use this in automation and then a team member in my BB accidentally declines a branch it creates more work

[rarkins]

I don't think we can change the current behavior because most people decline the PR intentionally.

[jerome-nelson]

The change isn't the issue - it would be nice to have. The issue is the lack of clear guidelines - so a simpler solution:

1. We edit the BB Cloud Onboarding Comment to inform new users not to decline PRs
2. Update the Docs https://docs.renovatebot.com/getting-started/installing-onboarding/ to add some kind of warning for BB Cloud users.

Please bear in mind, I mention Onboarding, but any PR which is declined on BB Cloud will have this issue

[tbugfinder]

I'd also like to add that the Bitbucket environment requires some sort of force recreating the onboarding pullrequest.
A PR decline might be intentionally at some point in time however one year later recreating onboarding PR might be the intented target but not possible as tooling is too strict.
As mentioned before, first renovate steps might also end up in declining the PR without "knowing" the logic that the declined PRs have side-effects.
Unfortunately work on #11594 stopped.