baseBranches, but only when they exist

[travi]

Which Renovate are you using?

WhiteSource Renovate App

Which platform are you using?

GitHub.com

Have you checked the logs? Don't forget to include them if relevant

i think this is working as currently intended, and i appreciate the warning issues to encourage fixing config problems early.

What would you like to do?

I'm a heavy user of semantic-release. one of the things that it has greatly improved in my workflow is making pre-releases very easy. by default, semantic-release will publish to alpha and beta release channels for changes pushed to alpha and beta branches, respectively. while i do try to keep these pre-release branches short-lived, there are times that i will consume a pre-release in a pre-release of another package. i would especially like pre-releases of the dependency that i'm working on to be PR'ed into the pre-release branch of the consumer, but would also find value in PRs for other updated dependencies that happen while the pre-release branch exists.

After finding the baseBranches config option, i thought this would accomplish what i wanted. I added this to my base config for js-packages, but was quickly informed that i made some incorrect assumptions. I assumed that it would only apply if the branch existed, but it makes sense why it could be seen as incorrect config when the branch does now exist.

Is it currently possible to configure baseBranches, or something similar, in a way that only applies when the branch exists? Also, since the default branch needs to be re-specified, is there a way to more directly use the configured for the repository in question (especially important if specifying this in my base config that applies across many projects that could be in various stages of transitioning away from using master as the default branch)?

[rarkins]

Actually, I have been recently considering making baseBranches failures non-throwing/non-fatal, and this maybe seals it. The main challenge is that it's then hard to alert people in the app if they made a typo in a base branch name, but maybe that's an ok trade-off (we can still issue a warning in the logs).

[rarkins]

Also, since the default branch needs to be re-specified, is there a way to more directly use the configured for the repository in question

I don't understand what you mean here, sorry. BTW the choice to make the default branch re-specified was in order to give people the flexibility to not run Renovate on the default branch, which a few needed.

[travi]

The main challenge is that it's then hard to alert people in the app if they made a typo in a base branch name

this part gives me pause as well. maybe the default behavior could remain the same, but an additional flag could allow opting into the only-when-exists behavior?

I don't understand what you mean here, sorry

no worries. let me try to explain better.

since i'm hoping to configure this in a base config, i may extend in projects that are inconsistent in how the default branch is named. many are master. some may be main. others might have a reason to be something else. also, those that are currently master may change later and i wouldnt want that change to become out of sync with this config unknowingly.

so, i was just wondering if you've considered or already enabled a way to say "include the default branch, whatever it happens to be" rather than directly specifying the strings master, main, etc. this has the benefit of avoiding the issues i mentioned above, but also avoids watching additional branches that are unnecessary since a base config would need to include all options while each individual repo only has one of those options active at a time.

if this doesn't already exist, i could see something along the lines of ['@DEFAULT', 'alpha', 'beta'] as an option of how to specify something like this.

the choice to make the default branch re-specified was in order to give people the flexibility to not run Renovate on the default branch

this makes sense, and i think that its a good solution. i'm just wondering if there is a more dynamic way of re-specifying that it should be included than to hard-code the default branch name that could change over time (and get out of sync when configured in multiple places) or be inconsistent across projects when inheriting from a base config

[rarkins]

Transferring into the main repo. So there's two ideas:

1. New boolean flag baseBranchesOptional that suppresses any error if the branch is not found
2. A special term like @DEFAULT or $default that can be used in place of literal master or main branch names.

[travi]

In case it would be valuable to match the default branch token available now for actions: https://github.blog/changelog/2020-07-22-github-actions-better-support-for-alternative-default-branch-names/

[rarkins]

Proposed solution: No longer error and abort if baseBranches are missing, instead WARN and continue with any other baseBranches that do exist

[renovate-release]

🎉 This issue has been resolved in version 22.19.6 🎉

The release is available on:

• GitHub release
• 22.19.6

Your semantic-release bot 📦🚀

[travi]

thanks so much for working through this one! i'm excited to try it out. so excited that it looks like i was premature in adjusting my config and started seeing issues opened, like form8ion/mocha-scaffolder#75. could you share what the timing of roll-out will look like?

[rarkins]

I'm pretty sure it's live now. Can you try again?

[travi]

sure thing. i reintegrated with form8ion/renovate-config@93cdd49 and haven't seen any new issues opened.

looking forward to seeing the new branches get PRs soon. thanks again!

[rarkins]

Just to double check, you don't have any of those branches yet, right? https://github.com/form8ion/renovate-config/branches

I also see that form8ion/mocha-scaffolder#75 was automatically closed, so that's a good sign

[travi]

you don't have any of those branches yet, right?

i'm not actively working any of them right now. i certainly do not have them in all repos, but i may have a few alpha branches here and there that i haven't gotten back to recently.

I also see that form8ion/mocha-scaffolder#75 was automatically closed, so that's a good sign

yep, along with several others after i pushed the shared config. those closed because of me reverting my change to enable the new branches. i re-reverted to re-enable in the commit above and no new issues have been opened.

[travi]

for a quick update, i've been seeing activity on branches that i havent gotten merged (i have more than usual right now for unrelated reasons) to add the branch name to the PR title (I like it 😄).

i did have one pin-dependencies PR opened for a beta branch. it was a stale branch that wasn't cleaned up from a while ago, so i closed the PR and deleted the branch since i don't need it anymore.

looking good so far

[travi]

and now an update PR for an existing alpha branch: travi-test/semantic-release-tester#215 👍

[rarkins]

Great, thanks for the feedback!