Skip to main content
Skip table of contents

Remediate and Scheduling

This article explains the two types of Scheduling Jobs used in Remediate/Renovate.

Pull Request Scheduling

Renovate - and therefore Remediate - has a “schedule” config option which controls when Branches and Pull Requests should be created. Users usually configure schedules, if they want to reduce the number of created PRs, or PRs created within working hours.

What this means in practice is that every time Remediate runs on a repo, it checks whether the configured schedule(s) match against the current time, and it skips creating ‘update branches/PRs’, if the schedule is not met.

Remediate’s scheduling capability can be configured within the .whitesource under remediateSettings field in the same way it can be configured in Renovate’s renovate.json fields:

CODE
"remediateSettings": {
      "enableRenovate": true,
      "extends": ["schedule:monthly"]
      }

If you are new to Renovate, we recommend you start with the config:base preset config, which enables functionality such as maximum two dependency update PRs per hour as well as grouping well-known monorepo dependencies together:

CODE
"remediateSettings": {
    "enableRenovate": true,
    "extends": ["config:base"]
    }

 

Note: vulnerability remediation PRs bypass any configured schedules or grouping, and are created immediately regardless of the schedule. Therefore configured schedules in .whitesource file only apply to non-vulnerable updates (“Renovate PRs”).

Job Scheduling

Remediate itself uses a job queue concept, and processes repositories one at a time in job priority order. Webhooks - such as for when vulnerability issues are created, or Pull Requests are merged - trigger high priority jobs. Meanwhile, Remediate has a “job scheduler” which enqueues every repo for a low priority job regularly so that repos are eventually all processed even if there are no webhooks trigger jobs.

Remediate’s “job scheduler” defaults to enqueueing jobs once per hour (at the top of the hour). There is usually no need to enqueue jobs any more frequently, unless debugging or testing.

When in Remediate-only mode ("enableRenovate": false), the frequency of the job schedule doesn’t matter, because Remediate should always receive webhook notifications whenever there is a new vulnerability found, or when one of its PRs is merged. Scheduled jobs are only useful in case events were lost, which shouldn’t happen frequently.

When Renovate functionality is enabled ("enableRenovate": true), then job frequency matters, because users can configure jobs with hourly granularity (e.g. between 2 am and 3am).

Note: the default job scheduling of Remediate is once per hour (at the top of the hour).

Ways to change the job scheduling times:

  1. Change the schedule at runtime of the Remediate Container by passing a ‘-e’ parameter with your schedule of choice (standard cron). For example, if I wanted to increase the frequency to every 30 minutes, you would add this at run time:

    CODE
    -e SCHEDULER_CRON="*/30 * * * *"
  2. Add it as an environment variable in the Remediate Dockerfile (or in a helm chart):

    CODE
    ENV SCHEDULER_CRON # Optional, defaults to '*/30 * * * '

    The recommendation is to add it on the next line after this:

    CODE
    # Remediate
    ENV WS_PLATFORM enterprise
    ENV SCHEDULER_CRON # Optional, defaults to '*/30 * * * '
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.