Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

duffle build should error/warn on unknown elements #363

Open
itowlson opened this issue Nov 5, 2018 · 2 comments
Open

duffle build should error/warn on unknown elements #363

itowlson opened this issue Nov 5, 2018 · 2 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@itowlson
Copy link
Contributor

itowlson commented Nov 5, 2018

If you add an unknown element to duffle.toml then it still builds. Although this appears benign, it has compatibility implications because an ignored element could become significant in a future build of duffle, changing the behaviour of an existing duffle.toml in unpredictable ways. It would therefore be good to warn or error if we see an element we don't know how to process.

name = "htest"
version = "0.2.0"
foobar = "foo and indeed bar"    # NO! NO! NO!

[components]
    [components.cnab]
        name = "cnab"
        builder = "docker"
        configuration = { registry = "itowlson-not-really-2" }
@bacongobbler
Copy link
Contributor

bacongobbler commented Nov 6, 2018

I do agree that it'd be nice to warn the user on elements that were not visited, but at the same time it might be possible that a wrapper or a plugin for duffle might re-use that manifest and add its own configuration. As an example, ~/.aws/credentials is shared amongst many sub-projects:

  • the AWS CLI itself
  • s3cmd
  • boto3

All of which share the same credential configuration that the AWS CLI configures via aws configure, but then add their own metadata to ~/.aws/credentials. Examples include the backup interval for s3cmd sync, or certain feature flags for boto.

In other words, I like the idea of warning on unknown elements but I also don't want to block out the use case that other tools may want to extend duffle.toml/duffle.json for their own needs. Can we figure out a way to accomodate both use cases?

@itowlson
Copy link
Contributor Author

itowlson commented Nov 6, 2018

Yes, we could reserve part of the namespace for vendor data. For example, we could say that all non-dotted names are validated, but dotted names are available for vendor data, with the suggested convention of vendorname.elementname. (Though we already have component.blah so maybe we are going to need more dotted names of our own.) Or that you can add a [extensiondata.*] grouping at any level, and anything under such a heading is ignored, though that's not lovely for an authoring experience (which is what this is meant to be).

@radu-matei radu-matei added good first issue Good for newcomers help wanted Extra attention is needed labels Feb 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants