Renovate: All branches are 'Skipping branch as it is not scheduled'

[Autre31415]

In our deployment of renovate we have it running on a bot every hour and the intention was that any dependency that needs to be updated would be getting a PR as soon as it's detected when it runs. I've noticed that lately a lot of branches are being made but not any pull requests and I've discovered the branch skipping due to schedule in the command line.

The schedule feature didn't exist in its current form when I started using renovate, so I'm not sure how to get this original behavior back.

[rarkins]

Can you post your config?

[Autre31415]

{
  "enabled": true,
  "autodiscover": false,
  "packageFiles": [],
  "depTypes": ["dependencies", "devDependencies", "optionalDependencies"],
  "separateMajorReleases": true,
  "ignoreDeps": [],
  "ignoreFuture": true,
  "ignoreUnstable": true,
  "respectLatest": true,
  "recreateClosed": false,
  "rebaseStalePrs": false,
  "prCreation": "immediate",
  "automerge": "none",
  "branchName": "renovate/{{depName}}-{{newVersionMajor}}.x",
  "commitMessage": "Update dependency {{depName}} to version {{newVersion}}",
  "prTitle": "{{#if isPin}}Pin{{else}}Update{{/if}} dependency {{depName}} to version {{#if isRange}}{{newVersion}}{{else}}{{#if isMajor}}{{newVersionMajor}}.x{{else}}{{newVersion}}{{/if}}{{/if}}",
  "prBody": "This Pull Request updates dependency {{depName}} from version `{{currentVersion}}` to `{{newVersion}}`\n\n{{changelog}}",
  "maintainYarnLock": false,
  "yarnMaintenanceBranchName": "renovate/yarn-lock",
  "yarnMaintenanceCommitMessage": "Renovate yarn.lock file",
  "yarnMaintenancePrTitle": "Renovate yarn.lock file",
  "yarnMaintenancePrBody": "This PR regenerates yarn.lock files based on the existing `package.json` files.",
  "groupName": null,
  "groupSlug": null,
  "groupBranchName": "renovate/{{groupSlug}}",
  "groupCommitMessage": "Renovate {{groupName}} packages",
  "groupPrTitle": "Renovate {{groupName}} packages",
  "groupPrBody": "This PR renovates the package group \"{{groupName}}\".",
  "labels": ["renovate"],
  "assignees": [],
  "reviewers": [],
  "pinVersions": true,
  "logLevel": "info",
  "platform": "gitlab"
}

This is the default config from onboarding at the time that was done (With the addition of a renovate label)

[rarkins]

Sorry, I'm not sure why that would be. You can definitely simplify your config though. Could you try changing it to:

{
  "extends": [":app"],
  "labels": ["renovate"]
}

I don't have a reason why that would fix it, but you never know. If it doesn't, can you capture the log at debug level and attach to here (if non-sensitive) or email to me directly if you prefer it not to be public ([email protected]).

BTW default behaviour with your old config includes lock file maintenance (updating/refreshing) scheduled for monday mornings so that will cause "not scheduled" logs for those.

a lot of branches are being made but not any pull requests

Your config says, "prCreation": "immediate", so that shouldn't be happening - a PR should follow all branches. Newer default behaviour is prCreation=not-pending, which means Renovate waits either for all tests to pass or at least one to fail before it alerts you with a PR.

[rarkins]

Based on logs you emailed me, it looks like:

• Renovate thinks the branch doesn't exist
• Renovate then fails to create the branch because it really does exist

..which seems to lead to a conclusion that the branchExists() check is incorrectly returning false.

I recently made some change to GitHub API related to api v4 https://github.com/singapore/renovate/commit/ddbbacb363bd52524a7196b2210ca2414c91c6cc#diff-fe2d49d57540680fde8e5194ae985951 due to https://github.com/singapore/renovate/issues/749

Maybe you are using a version of the GitLab server that doesn't support escaping? I had hoped it would work for all versions but maybe not.

[rarkins]

@Autre31415 could you provide me an update on this? e.g. did you roll back to a new version, or is it working now, or you paused renovate, or.. ?

[Autre31415]

I've determined what caused this issue, and it's related to server configuration. I'll outline it here and if you'd like you could toss something in the docs about it in case others have a similar issue.

It all started with Gitlab 9.5 introducing the need to encode the / character in the branch name. Depending on how the web server that hosts the Gitlab instance is configured, encoding that character in the URL could cause issues accessing that branch route. This is due to Gitlab expecting slashes to not be decoded as noted here. This issue is compounded if your setup uses another web server (Such as apache) to proxypass over to nginx on the route, and can cause the character to be double encoded. The end result is not being able to access the branch.

Fixing this requires all proxies related to Gitlab be set to not decode characters in the URL.

It seems the Gitlab devs aren't too fond of the concern of character encoding in routes, so it's possible at some point it will be changed again.

[rarkins]

Thanks for the detailed description. We should ideally add this to a doc as it will be helpful to others.