Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the Buildpack API version check more robust #421

Merged
merged 2 commits into from
Jun 22, 2022

Conversation

edmorley
Copy link
Member

@edmorley edmorley commented Jun 21, 2022

Previously, if a buildpack.toml either:

  1. Didn't match the specific custom buildpack type (used when custom fields are specified under [[metadata]])
  2. Didn't match the CNB spec

...then a generic "failed to deserialise buildpack.toml" message was shown, rather than any error about the buildpack API version not matching.

In cases where the chosen API version is actually the cause of the error (for example if a future API version makes breaking changes to the schema), then this means the underlying cause isn't mentioned.

Now, the check uses a minimal BuildpackDescriptorApiOnly type when deserialising buildpack.toml, to ensure the API version can still be determined in those cases.

The BuildpackDescriptorApiOnly type was used instead of a raw toml::value::Table, since otherwise there are a myriad of Options and related to handle, from both the potential lack of api field and it not having a value of type string etc.

GUS-W-11324328.

@edmorley edmorley self-assigned this Jun 21, 2022
Previously, if a `buildpack.toml` either:
1. Didn't match the specific custom buildpack type (used when
  custom fields are specified under `[[metadata]]`)
2. Didn't match the CNB spec

...then a generic "failed to deserialise buildpack.toml" message was
shown, rather than any error about the buildpack API version not
matching.

In cases where the chosen API version is actually the cause of the
error (for example if a future API version makes breaking changes
to the schema), then this means the underlying cause isn't mentioned.

Now, the check uses a minimal `BuildpackDescriptorApiOnly` type
when deserialising `buildpack.toml`, to ensure the API version can
still be determined in those cases.

The `BuildpackDescriptorApiOnly` type was used instead of a raw
`toml::value::Table` since otherwise there are a myriad of `Option`s
and related to handle, from both the potential lack of `api` field and
it not having a value of type string etc.
@edmorley edmorley force-pushed the edmorley/improve-api-version-mismatch-check branch from 790e5f3 to 6d5d9aa Compare June 21, 2022 12:03
@edmorley edmorley marked this pull request as ready for review June 21, 2022 12:06
@edmorley edmorley requested a review from a team as a code owner June 21, 2022 12:06
Copy link
Member

@Malax Malax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to make BuildpackDescriptorApiOnly public? I'm fine with it, but it feels like an internal-only data structure.

@edmorley
Copy link
Member Author

@Malax Yeah I wasn't sure if it should be or not. I can move it into runtime.rs and make it private perhaps?

@Malax
Copy link
Member

Malax commented Jun 22, 2022

@edmorley Yeah, that is what I had in mind. 👍🏻

@edmorley edmorley force-pushed the edmorley/improve-api-version-mismatch-check branch from bb87511 to 85655e6 Compare June 22, 2022 11:49
@edmorley edmorley merged commit af19436 into main Jun 22, 2022
@edmorley edmorley deleted the edmorley/improve-api-version-mismatch-check branch June 22, 2022 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants