Why am I seeing a GitLab external job "renovate/stability-days"?

[gaeljw]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

44.52.1

Please tell us more about your question or problem

Hello folks,

I'm seeing this external job in a GitLab CI pipeline for the 1st time even though we're using Renovate for years.

I roughly understand what it relates to: the Minimum Release Age feature.

But I don't understand why I'm seeing it on this project while every other project I have do not show this external job in their pipelines.

My guess is that it somehow relates to the fact that there's no pipeline configured for the MR/branch/commit event in this project, there's only a pipeline on manual triggers.

I don't mind it even though a bit confusing, I'm just trying to understand why it would appear on this project only 🤔

Thanks for any info about this.

Logs (if relevant)

No response

[jamietanna]

Hye, so you're seeing this because we set statusCheckWhen.minimumReleaseAge=always by default

It's unrelated to the CI status of the repo, and is more Renovate saying "this package has met minimumReleaseAge" or "this package has not met minimumReleaseAge", and allows folks to require the status check be passing before they allow a MR to be merged

When Renovate is aware of a package's releaseTimestamp, which powers minimumReleaseAge, it's more useful

In terms of why on this project only, I'm unsure - maybe if you can share what other repos/dependencies you're seeing it on/not on that'd help

[gaeljw]

Thanks @jamietanna. I'll report back with a few examples early next week.

But isn't Renovate supposed to not even create a branch nor open a MR if the MRA is not reached?

[jamietanna]

But isn't Renovate supposed to not even create a branch nor open a MR if the MRA is not reached?

It depends :)

Someone's repo config may tune minimumReleaseAgeBehaviour and internalChecksFilter to still allow MRs to be raised, even if the minimumReleaseAge isn't yet met. So in those cases, getting a status check that's pending allows them to block the merge

[gaeljw]

I verified, we have "minimumReleaseAgeBehaviour": "timestamp-optional" and no config for internalChecksFilter (extending config:best-practices).

In terms of what repos I've observed this or not: I thought I only ever observed this job in the one repo I mentionned earlier (vs. hundreds of other repos where it never showed up).
But... having another look at some other NPM repos, I do see it as well:

Branch pipeline (we don't use them):

MR pipeline:

(Dependency jasmine-core is aged 19d as of writing this)

I probably never noticed because:

• this only appears for NPM dependencies I guess (95% of our dependencies are Maven based, through an internal proxy registry for which the age doesn't seem to be preserved, hence the usage of timestamp-optional)
• this appears on "branch" pipelines and they appear at the end after the "merge request" pipelines, so we don't really see them if not explicitly going to the "pipeline" tab in GitLab UI
• this appears on "merge request pipelines" but as the last step after our regular 7-8 steps and it didn't pop to my eyes that there was an extra step at the end which was not defined by us 👀

---

Another thing is that on some MR, I see this warning:

⚠️ Renovate does not enforce Minimum Release Age for bump, lockfileUpdate, or rollback updates, so these are raised without a Minimum Release Age check. You will need to manually validate the Minimum Release Age for these package(s).
Not sure why though as the update is:

---

Bottom line: I probably never noticed, this isn't new.

I find it confusing to have this job given that this check will always be green/ok given our setup from what I understand but it's okay.

[jamietanna]

Related: #45713

[gaeljw]

In my case we use only the default "merge request pipelines", not "merged results pipelines".