feat: buildkite plugin renovation

[rarkins]

This PR adds initial support for buildkite plugin renovation.

It supports plugin-name or my/plugin-name plugins, and fully specified semver versions only (e.g. v1.3.2). Currently it will always propose an upgrade to the latest version available, e.g. if current version is v1.3.1 and both v1.3.2 and v2.0.0 exist then v2.0.0 will be proposed.

Future work:

• Support git hash references in addition to semver versions
• Support fully specified git repositories
• Support more than one plugin inside a plugins: entry
• Split major/minor updates into separate PRs, like we do with npm dependencies
• Get release notes working

Closes #1869

[rarkins]

@KevinGrandon could you take a look here? I think this is nearly good to merge, however I don't think the current filePattern regex meets your requirements:

• Renovate all yaml files that have plugin references in the .buildkite/ folder.
• Have a configuration to match pipeline files not inside of the .buildkite/ folder and renovate them.

Do you want it to check every *.yml file inside .buildkite plus any file named pipeline.yml anywhere else in the repository? Right now we only do the latter.

cc @lox @toolmantim

[codecov]

Codecov Report

Merging #1874 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           master   #1874   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files         110     114    +4     
  Lines        4941    5010   +69     
======================================
+ Hits         4941    5010   +69

Impacted Files	Coverage Δ
lib/config/definitions.js	100% <ø> (ø)	⬆️
lib/manager/index.js	100% <ø> (ø)	⬆️
lib/manager/buildkite/extract.js	100% <100%> (ø)
lib/manager/buildkite/package.js	100% <100%> (ø)
lib/manager/buildkite/index.js	100% <100%> (ø)
lib/manager/buildkite/update.js	100% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4bd721b...a89acc7. Read the comment docs.

[rarkins]

I have tested this against a couple of "real" repositories I found that use versioned buildkite plugins, including one of @toolmantim's: renovate-tests/docker-buildkite-plugin#4

I will merge this PR with the buildkit option disabled by default and leave it as opt-in until one of you gives it the thumbs-up to be enabled by default.

[toolmantim]

This is great! The logic all looks AOK.

Sorry if this is a silly question… I'm new to Renovate, but I'm wondering how release notes / commits are picked up? I noticed in renovate-tests/docker-buildkite-plugin#4 that there's no notes or commits, but there's notes in the Github releases: https://github.com/buildkite-plugins/docker-buildkite-plugin/releases

[rarkins]

@toolmantim release notes/changelog are picked up from the source GitHub repository normally. I also noticed that they were missing from that PR and meant check it later but forgot to note it in the Future work above. There's perhaps a small mismatch between the tag used and the release note slug, for instance - but in theory it should work fine and the same way as for npm.

[KevinGrandon]

This is awesome! Thanks for putting this together so quickly.

Do you want it to check every *.yml file inside .buildkite plus any file named pipeline.yml anywhere else in the repository? Right now we only do the latter.

Sorry for not being clear earlier. .buildkite/pipeline.yml is the canonical pipeline, though people often have other yml files inside of .buildkite for other pipelines. Some examples of use cases I have seen:

• .buildkite/pipeline.yml
• .buildkite/pipelines/foo.yml
• .buildkite/bar.yml

In addition, people may put pipelines outside of this folder, possibly in a top level pipelines/ folder. It seemed that renovating every yml file in an entire repo might not make sense, or possibly conflict with other systems.

After thinking about it a bit more and looking at other renovate config options, the following would be great to have:

• .yml file discovery in .buildkite/ (probably always on is fine)
• Additional buildkitePipelineFiles configuration, that allows people to specify yml files outside of .buildkite (probably less important and can come in a follow-up PR).

[KevinGrandon]

Left some comments above about pipeline file location, but this is a great start and would be totally reasonable to turn on and enable. Thanks so much for the quick turnaround here, this is amazing.

[rarkins]

@KevinGrandon thanks for the quick feedback too. i was intending to leave the meat of the PR for you but.. once I got started it was hard to know where to stop :)

Re the file search, I agree that starting with any yml in .buildkite/ is reasonable. I'll adjust the regex now.

I have a generic feature coming up for manually configuring other filenames/locations for any package manager, so we can pick up the buildkite one later that way, as you suggest.

[renovate-bot]

🎉 This PR is included in version 12.7.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀