The release drafter action expects the buildpack.toml file it reads for a buildpack to be at the root of the project repo and it expects there to be only one. If you have multiple buildpacks in a repo, the buildpack.toml won't be in the root and the tool will need to know how to locate the buildpack.toml for the specific buildpack.
Possible Solution
There are two parts:
Given the buildpack image reference, we need to be able to locate the Github repo. For example, given gcr.io/paketo-buildpacks/bellsoft-liberica we need to find https://github.com/paketo-buildpacks/bellsoft-liberica. This is basically done with the "mapper" feature of the release drafter. You can configure regex mappers in the buildpack-descriptor.yml and control how it translates from one to the other.
Once we've found the Github repo, we need to find the appropriate file under that repo. Right now, it's hardcoded to /buildpack.toml. We then use the Go Github client to fetch the file from the repo.
A possible solution is to add a buildpack.toml location map to the pipeline-descriptor.yml file.
We could also potentially try to have a convention that we follow here. For example, if the folder <org>/<name> exists or <name> exists, we'd try that first. If they don't exist, then use the manual bp-toml-mapping, if that doesn't work fail.
Describe the Enhancement
The release drafter action expects the buildpack.toml file it reads for a buildpack to be at the root of the project repo and it expects there to be only one. If you have multiple buildpacks in a repo, the buildpack.toml won't be in the root and the tool will need to know how to locate the buildpack.toml for the specific buildpack.
Possible Solution
There are two parts:
Given the buildpack image reference, we need to be able to locate the Github repo. For example, given
gcr.io/paketo-buildpacks/bellsoft-liberica
we need to findhttps://github.com/paketo-buildpacks/bellsoft-liberica
. This is basically done with the "mapper" feature of the release drafter. You can configure regex mappers in the buildpack-descriptor.yml and control how it translates from one to the other.Once we've found the Github repo, we need to find the appropriate file under that repo. Right now, it's hardcoded to
/buildpack.toml
. We then use the Go Github client to fetch the file from the repo.A possible solution is to add a buildpack.toml location map to the pipeline-descriptor.yml file.
We could also potentially try to have a convention that we follow here. For example, if the folder
<org>/<name>
exists or<name>
exists, we'd try that first. If they don't exist, then use the manual bp-toml-mapping, if that doesn't work fail.Motivation
Support a monorepo design.