Add renovate config for buildpacks

[nicolasbender]

Summary

This serves as a basic configuration for dependency updates via renovate for buildpack repositories. Currently, this replaces dependabot updates only, so every dependency managed by paketo-bot needs some more investigation.

Use Cases

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[pacostas]

Do you konw it if the PRs opened by the renovate, are going to be approved by the approve buildpacks workflow?

[pacostas]

Also I think that upgrading the API version of the buildpack.toml to its latest, might not be very useful, as for each buildpack there is migration that needs to be done, between each api version. I would suggest if is feasible, instead of always going to the latest version, to go to the next version from what currently the api is.

[jericop]

I have limited experience with renovate, but it looks like this PR adds a config to update the api version in buildpack.toml files. I imagine each buildpack repo would need to be configured to use this config, so it would not apply automatically by default. Please correct me if I’m wrong.

I agree with @pacostas that we probably don’t want to update the api version from buildpacks/spec to latest without some planning and migration.

I see a potential middle ground though. Perhaps we could create our own repo where we create releases with the target api versions (matching valid buildpacks/spec releases) we want all paketo buildpacks to be at. This would allow us to use renovate to keep api versions in sync across repos in a consistent way, as intended by this PR. It would also give maintainers control over when to update api version and allow for any updates to tooling, workflows, etc.

[pacostas]

I have limited experience with renovate, but it looks like this PR adds a config to update the api version in buildpack.toml files. I imagine each buildpack repo would need to be configured to use this config, so it would not apply automatically by default. Please correct me if I’m wrong.

Yes that is true, we need to follow the instructions from here https://github.com/paketo-buildpacks/github-config?tab=readme-ov-file#dependency-updates in order for the repo to get updated by the renovate.

I see a potential middle ground though. Perhaps we could create our own repo where we create releases with the target api versions (matching valid buildpacks/spec releases) we want all paketo buildpacks to be at. This would allow us to use renovate to keep api versions in sync across repos in a consistent way, as intended by this PR. It would also give maintainers control over when to update api version and allow for any updates to tooling, workflows, etc.

Can you please add an example or explain a little bit more about this idea? I think I cant understand what the output result from this one should be.

[jericop]

Can you please add an example or explain a little bit more about this idea? I think I cant understand what the output result from this one should be.

Let's say we create a new repo called paketo-buildpacks/cnb-buildpack-api-version . The repo name can be anything, but just trying to identify the purpose of the repo in the name.

Now let's say we have a file called targets.json in that new repo with the following structure.

{
  "buildpack_api": {
    "source_repo": "buildpacks/spec",
    "artifact_name": "buildpack",
    "version": "0.11"
  }
}

Lastly, lets say we have GitHub workflows that cut a release to match the version in targets.json whenever a PR is merged into the repo.

We can then point renovate to paketo-buildpacks/cnb-buildpack-api-version instead of buildapcks/spec as the source for the versions renovate should update to.

[pacostas]

I agree having a repo that stores all the api versions. Do you think we can also fetch the api versions from the release https://github.com/buildpacks/spec/releases with the gh cli? The release notes seem pretty consistent and updating the content of the paketo-buildpacks/cnb-buildpack-api-version might need another github action that probably will fetch the content from the releases or it might have to be maintained manual.

In terms of having all buildpacks at the same api version, I think this might be blocking for other buildpacks from upgrading to a latest version or a much grater than what renovate might suggest. E.g. for node-engine, where we use the api 0.10 compared to the majority of the buildpacks that are on version 0.7. I think it would be preferable if each buildpack could upgrade separately, without having to follow the same api as the rest of the buildpacks.

[jericop]

@nicolasbender can you remove the custom manager from the renovate config when you get a chance? We are not ready to automatically bump buildpack api versions. We can then proceed with this PR so we can swap out dependabot for renovate as intended.

[nicolasbender]

Do you konw it if the PRs opened by the renovate, are going to be approved by the approve buildpacks workflow?

Approval still needs to be done manually or with a workflow I assume, but we can set auto-merge with renovate.

I would suggest if is feasible, instead of always going to the latest version, to go to the next version from what currently the api is.

This then sounds like a process that should not be automated by a dependency manager. I only included it because it was a dependency that is different from other repositories.

it looks like this PR adds a config to update the api version in buildpack.toml files. I imagine each buildpack repo would need to be configured to use this config, so it would not apply automatically by default.

Yes that's correct. This PR adds specialized configuration for buildpack repositories which those then can refer to when it is planned to onboard them to renovate.

We can then point renovate to paketo-buildpacks/cnb-buildpack-api-version instead of buildapcks/spec as the source for the versions renovate should update to.

I am not sure how the current procedure for updating the buildpack spec for each repository looks like, but I am not sure if this kind of automating dependency management provides much value in contrast to updating the spec manually after applying necessary changes. But maybe you can give an example how the process of bumping the buildpack spec version would look like.

[jericop]

I am not sure how the current procedure for updating the buildpack spec for each repository looks like, but I am not sure if this kind of automating dependency management provides much value in contrast to updating the spec manually after applying necessary changes. But maybe you can give an example how the process of bumping the buildpack spec version would look like.

I was just throwing an idea out there and am not suggesting we do this or prioritize it right now. We’ll keep updates to buildpacks api a manual process for now.