Add label to onboarding pull requests

[HonkingGoose]

What would you like Renovate to be able to do?

A user asked:

The RENOVATE_ADD_LABELS env var is great to add labels to the MR's, however is there a way of adding specific ones to the onboarding MR's, so I can add a 'onboarding' label to only those?

@rarkins liked this idea. I'm creating this issue to discuss the requirements some more, and to track this idea. 😄

If you have any ideas on how this should be implemented, please tell us here.

We already have a addLabels feature, maybe the code for that can inspire the new code?

• Write code for new feature
• Create Renovate built-in preset to add a onboarding label that users can extend from
• Mention onboarding labels in the addLabels docs
• Explain in the docs how a maintainer can tell Renovate to add the onboarding label to new onboarding PRs

Is this a feature you are interested in implementing yourself?

No

[HonkingGoose]

Adding labels to a onboarding PR that you'll usually get once per repository, is probably low-priority, or even wont-do territory. What do you think @rarkins?

[slonim-greg]

I wanted to inquire if this is something that you can consider implementing or reviewing a contribution for.

Context
In our organisation, there are strict pre-flight rules on MRs/PRs, specifically, their correlation with Jira tickets, among other policies. Adding a label/labels to these onboarding MRs will allow us to remove friction in onboarding repos for the bot (where we can bypass these policies automatically based on labels). Please share your thougths.

[rarkins]

We are adding inheritConfig support to the hosted app too, so long as users use the default file naming convention

[HonkingGoose]

Two questions for @rarkins:

• Do we have an issue on the renovatebot/renovate repository to directly track "add inheritConfig support to the hosted app"?
• Or is improvement already tracked in a Mend-internal todo?

Open issues I found that seem relevant

Searching for inheritConfig gives no open issues. But searching inherit config leads to:

• Inherited config should be resolved before merging #31278

I skimmed the open issues labeled with core:config. I think these are somewhat relevant:

• Allow configurable repo config file names #29536
• Support for dynamic repository configuration #21110
• Add globalPresets and repoPresets to global config, deprecate direct extends use #11791
• Generic/improved config file naming approach #10682

[rarkins]

I think maybe we can have open discussions when it relates to the Mend app, and reserve issues for things which are related to code in this repo.

@justo-mend what's the status of inheritConfig support in the Mend app?

[justo-mend]

The inheritConfig feature is enabled and working on the cloud-hosted Mend Apps. (Documentation is pending PR approval)

To use inherited config:

1. Include the config in a file called "org-inherited-config.json" in a repo called "renovate-config" within the same org.
2. Ensure the "renovate-config" org has Renovate enabled

Note: the feature only takes effect when the org-inherited-config.json file is added or modified AFTER the repo (renovate-config) has had Renovate installed. (Onboarding not required)

[HonkingGoose]

The documentation changes are published now:

• docs: Added documentation about inherited config for the Mend-hosted app #31479