search

renovatebot / app-support

Discussion/support issues for the hosted Renovate App
0 stars 0 forks source link

Getting PRs as soon as possible #7

Closed simoneb closed 5 years ago

simoneb commented 5 years ago

Which Renovate are you using? CLI, App, or Pro

App

Which platform are you using? GitHub, GitLab, Bitbucket Azure DevOps

GitHub

What is your question?

We are using Renovate to bump internal package versions and we would need it to do it as timely as possible after a package is released.

We're not watching closely how long on average it takes, but we've seen some cases when getting a PR from Renovate was very slow. There was one case where a PR for bumping a package version happened at 10:51AM MDT (can't tell exactly when the package was published to our private registry but I imagine a few minutes later), but we didn't receive a renovate PR until 5:31PM MDT, so hours later.

For internal packages we're using the "at any time" schedule.

rarkins commented 5 years ago

Is the repo private? Are the packages published on npmjs privately or a separate registry? If you log into the dashboard, does it report any jobs occurring between when the package was published and when the PR was created?

simoneb commented 5 years ago
simoneb commented 5 years ago

I have an example. We released a package at a certain time yesterday, this is the output of the npm view command:

 '0.5.30': '2019-08-19T15:37:38.000Z'

This is the job that ran: 88900915

The PR was created by Renovate to bump to that package version at 7:08PM GMT+2, which is 2+ hours after the package was published.

rarkins commented 5 years ago

Sorry, I missed this update at the time. Renovate is set to queue repos every hour although during high load then not all repos might get serviced each our. Because private registries have no link to Renovate for new release notification or cache invalidation, it’s a matter of the new release being detected the next time Renovate runs on schedule - it can never be instant.

I’d expect 2 hours to be pretty normal but 3+ is undesirable. A key thing is noting whether there was any runs in the logs after the release but before the PR was created.

Please also paste your config here.

simoneb commented 5 years ago

Ok I understand, thanks for the clarifications. Is there a way for us to get those PRs more quickly? Just for our internal packages.

Here's the (redacted) configuration:

{
  "extends": ["config:base"],
  "statusCheckVerify": true,
  "ignoreDeps": [redacted],
  "schedule": ["every weekend"],
  "labels": ["renovate"],
  "packageRules": [
    {
      "packageNames": [redacted], <-- this is one of our internal packages for which we'd want timely PRs
      "groupName": redacted,
      "assignees": [
        redacted
      ],
      "schedule": ["at any time"]
    }
  ],
  "vulnerabilityAlerts": {
    "labels": ["SECURITY"]
  },
  "encrypted": {
    "npmToken": redacted
  },
  "npmrc": redacted
}
rarkins commented 5 years ago

I just pushed a new feature to the app. If you add "masterIssue": true to your config then you'll get a mini-dashboard "Master Issue" added to your repo. Down the bottom is an "Advanced" section which lets you tick a box to request a new run on your repo at any time. So in cases where you're impatient for an update, ticking this box should put your repository to the front of the queue and speed it up.

image