# nansible Release Notes

## 4.0.2

- fixed an issue with the pg commands where they would fail if the output
  contained any extra non-query information

## 4.0.1

- added a new meta-command `anyCommandOf` to run multiple commands in
  succession until one succeeds
- fixed an issue with `c.ensure` directives swallowing the error of the last
  failing task

## 4.0.0

A breaking change has been made to how aborting tasks are handled. Previously,
all "pre-condition" tasks (those defined using [[commands.core.ensure]]) would
be applied even if one of them fails. The intent was to report as many errors
to the user as possible in the same run.

However, this could no longer be done reliably since the introduction of
registers/variables as a pre-condition could rely on a [[commands.core.setVar]]
directive which would *not* be applied in case of a failure.

In this release, nansible will abort as soon as any pre-condition is not met.

## 3.0.1

- fixed an issue in bash script `run.sh` not honoring the verbose flag on some
  cryptic linux distro

## 3.0.0

- `verbose` mode will now output the context of shell commands (e.g. cwd and
  env vars)
- (breaking) `commands.core.exists` is now inside the [[commands.file]] module
- (breaking) `commands.core.task` no longer accepts a "creates" argument. To
  subsitute, use `unless: c.file.exists()`
- the shell module now uses the more portable `.` operator instead of `source`
  for executing commands
- added a new tty helper: [[commands.tty.underline]]
- task failures that provide an Error will now have their stack trace
  printed along with the error. This is an enhancement only for user-defined
  modules since nansible's official modules do not provide such errors.

## 2.0.2

- fixed an issue where shell commands asked to run from a directory that does
  not exist would cause an internal failure
- added yaml parser in [[commands.var.yaml]]
- fixed an issue where the output of the [[commands.prompt.confirm]] prompt was
  not visible to the user unless verbose was set
- fixed an issue with [[commands.core.log]] statements not being output unless
  verbose was set
- fixed an issue with [[commands.core.log]] statements being lost if the
  process exited too quickly

## 2.0.0

- nansible now supports progress-reporting through a minimalist spinner
- the evaluation of directives during an application has been revisited once
  again to correct more issues such as certain parameters passed to
  [[commands.core.task]] not being interpolated with dynamic parameters (e.g.
  variables)
- (breaking) [[./lib/apply.js]] no longer performs any reporting or logging. To
  achieve the previous effect, use [[./lib/applyWithLogging.js]] instead.
- a new application parameter `startAtTask` is now supported that will make the
  application ignore any tasks prior to the specified one. This is similar to
  ansible's `--start-at-task=name` CLI option.
- `ABORT` tuples (generated via [[commands.core.ensure]]) no longer short-
  circuit the application
- performance of [[commands.core.task]] has been improved
- implementation of [[commands.tty.nws]] has been revisited to yield more
  accurate results

Internal:

- (breaking) `BOUNDED` tuple has been renamed to `BRANCH` for consistency with
  other tuple names (nouns and not adjectives)
- History no longer performs logging. Instead, it accepts an `onChange`
  function that is called anytime an entry is added.

## 1.3.0

A major change to how conditionals work is introduced by release.

[[commands.core.ifElse]] and variants are no longer evaluated at the start of
an application, instead they are evaluated upon encountering. Internally, a
conditional directive now generates a proper Tuple `BOUNDED` comprising the
predicate and the two branches of directives. That tuple is then evaluated by
the applier.

What this means in terms of application layer is that conditionals can now rely
on side effects from previous tasks; be they variables or external effects.

For example, the following playbook wouldn't work before since by the time
`c.ensure` is evaluated, the `setVar` directive wouldn't have been:

```javascript
[
  // this didn't work before
  c.setVar({
    name: 'something',
    value: true
  }),

  c.ensure(params => params.vars.something === true)
]
```

With this change, that example will function as expected.

Features:

- [[commands.core.log]] has received some love; it now supports "transformers"
  similar in a parameter similar to [[commands.core.setVar]]'s; the message
  will be passed through a pipe of transformations such as [[prepending a
  success or failure symbol | commands.tty.markFailure]] or [[padding the
  message | commands.tty.pad]].
- a new string helper for use in logging: [[commands.tty.bold]]
- a new string helper for use in logging: [[commands.tty.pad]]
- a new string helper for use in logging: [[commands.tty.nws]]
- a new string helper for use in logging: [[commands.tty.markFailure]]
- a new string helper for use in logging: [[commands.tty.markSuccess]]

Bug fixes:

- corrected an issue where environment variable templates passed to shell were
  not being interpolated

Other changes:

- (breaking) [[commands.core.setVar]] no longer accepts the `format` option;
  instead the `transform` property can now be a list of transformers which are
  applied as a pipe. In the place of `format: "json"`, one can now use:
  `transform: [ c.var.json ]`
- [[./lib/dump.js]] will now dump the command's environment variables
- marginally optimized the performance of [[commands.core.task]]
- [[commands.file.create]] will now interpolate the contents of the source file
  if `src` was specified
- `stringUtils.t` is now curried for your ~~flavor~~ convenience

## 1.2.2

- [[commands.shell.execRaw]] now supports an `env` option
- removed internal command `commands.shell.execUnbuffered` as it was a work-
  around for an issue fixed in version 1.2.0
- added a new var helper: [[commands.var.json]] for parsing json values
- added a new var helper: [[commands.var.shell]] for extracting stdout out of a
  shell command result

## 1.2.0

- corrected behaviour of [[./lib/exit.js]] so that it only sets
  `process.exitCode` and does not call `process.exit()` directly. This fixes an
  issue where process.{stdout,stderr} buffers do not get flushed prior to exit.
- implemented basic `setVar` directive
- `LOG` directive is now interpolated at application layer (instead of
  evaluation layer) to allow the use of variables
- play now contains a reference to the parameters it was run with
- `shell.exec` behaviour was changed; it now passes the command to a proxy
  shell script that takes care of redirecting stdout/stderr to files and to
  /dev/* if --verbose is set

## 1.1.0

- `commands.core.canUse` has been moved to the shell module:
  [[commands.shell.canUse]]
- [[commands.shell.canUse]] now accepts a template
- Dropped the use of [shelljs](https://github.com/shelljs/shelljs) because of
  cryptic errors around `exec` and a little too much magic to achieve
  `execSync` - now we use node's native [spawnSync](https://nodejs.org/api/chil
  d_process.html#child_process_child_process_spawnsync_command_args_options)

## 1.0.0

- Initial release