search

puppetlabs / puppet-specifications

Specification of the Puppet Language, Catalog, Extension points
Other
99 stars 66 forks source link

(SPEC) Add positional arguments to the task spec #128

Closed davejohnston closed 5 years ago

davejohnston commented 5 years ago

The objective of this change is to make integrating with existing scripts easier. i.e. rather than having to write an adapter to read json from stdin, or read environment variables, the user can just specify the metadata necessary to describe and execute their script.

davejohnston commented 5 years ago

@MikaelSmith @adreyer I am interested in trying to make it easier for customers to create tasks using their existing scripts (without having to make any modifications or create adapters). I'm looking at this from a discovery perspective - so proposing the above, whereby we could write a task where the task runner will pass parameters directly to the script in a specified order. e.g

my_script.sh or my_scripts.ps1

Do you think this is a reasonable thing to include in the spec ?

davejohnston commented 5 years ago

@MikaelSmith thanks - some good questions/comments. I'm going to get our current release out of the way and then come back and maybe create some worked examples for this,

adreyer commented 5 years ago

This was discussed as part of the original task spec. We ended up cutting it for a few of reasons:

  1. Most scripts need flags not positional arguments. Multiple positional arguments lead to bad scripts
  2. Proper escaping is difficult and results in user confusion when things break.
  3. Bolt can run scripts with positional arguments. If you have a script and don't want to turn it into a task just run the script. This format has better support for flags too.
  4. In my experience converting a script from flags or positional arguments takes <30m. It's pretty easy to do and results in a higher quality task long term. Since then:
  5. The new multi-file support for bolt means that you can write a simple wrapper for you script, put the script in files then execute the script with the wrapper. This decreases the time to convert a script to as task to <10m and solves the use case where the script is provided by a 3rd party and you don't want to. I've ticketed better documenting this process in BOLT-989.

I'm going to close this ticket.

@davejohnston if the underlying issue is the ability of discovery users to run preexisting scripts I think we should discuss just running scripts directly with bolt-server or boltshim rather then forcing users to convert those into tasks.