fireblinkltd / fbl Goto Github PK

Add ability to remove keys from "ctx" and "secrets" via custom handlers.

When fbl is invoked with relative path to the flow, e.g. subfolder/flow.yml - fbl resolves path as /path/to/subfolder/subfolder/flow.yml. (appends subfolder path to the absolute location of subfolder).

fbl https://github.com/FireBlinkLTD/fbl-plugin-template/archive/latest.tar.gz
 -> Downloading tarball from remote URL: https://github.com/FireBlinkLTD/fbl-plugin-template/archive/latest.tar.gz
 -> Extracting tarball at path: /var/folders/l2/jyv1k6js0yj3j__ppkc5zd04c_7vc6/T/tmp-8201Wzn5XIWbYJ1H.tar.gz
zlib: unexpected end of file

By comparing file size actual is 4kb while expected - 5kb.

Currently CLI ctx and secret assignment is not working same way as "assignTo" options.

Configure CircleCI to publish npm module upon git tag creation and successful tests pass.

Need to give option for user to store his/her default list of plugins inside the user's homedir config file at path $HOME/.fbl/config

Config should be presented with a YAML formatted content:

plugins:
 - fbl-test-plugin

secrets:
 shhhh: true

context:
 defaultValue: 'no'

Add new action handler that is capable on running any js function and has access to context and snapshot.

fn(): |-
   context.ctx.something = context.ctx.test > 0;

It might be handy to try the flow before applying the changes. Though some 3rd party plugins/actions may not support this. So update metadata to have supportsDryRunExecution boolean field. So that only action that support it will clearly state that.

Also add --dry-run command line option to dry run the flow. If any of the actions inside the flow doesn't support it - exceptions should be throws before validation and flow stopped.

Extend secrets loading to support "vaults", where vault can be any file encrypted with password or some key.

Similar to what flow already has - add support on defining required native apps to be installed by the plugin.

Upon releasing 0.3.0 CircleCI build failed with:

1) CliTestSuite
       testCustomTemplateDelimiters:

      AssertionError [ERR_ASSERTION]: { ct: 'yes', '.': { custom_ct: 'file1' }, test_1: 1, test_2: 2 } deepStrictEqual { test_1: 1, test_2: 2 }
      + expected - actual

       {
      -  ".": {
      -    "custom_ct": "file1"
      -  }
      -  "ct": "yes"
         "test_1": 1
         "test_2": 2
       }
      
      at CliTestSuite.<anonymous> (test/unit/cliTestSuite.ts:809:16)

However, at first sight it looks weird as "testCustomTemplateDelimiters" test doesn't operate with "custom_ct" field names inside it.

https://circleci.com/gh/FireBlinkLTD/fbl/231

Sometimes it may be useful to repeat some actions multiple times, but manually duplicating it's configuration inside the sequence/parallel action handler might be a pain.

Consider creating new "repeat" action that accepts following options:

# number of times to repeat action
times: 5

# some action to repeat
# iteration index should also be available for EJS template of the action
# index should always start with 0
action:
  dummy: 'Index: <%- index %>'

# Whether to run all actions in parallel or in a sequence, default value: false
async: true

If flow references to directory CLI and attachment action handler should use index.yml as a pipeline entry point.

We need to store path from where fbl was invoked inside the context.cwd field.

$.readFile.text();
$.readFile.base64();

There should be 2 embedded report generators: JSON and YAML, all others should be added via plugins.

So plugin interface needs to be updated to support report generators registration.

Currently interface contains only one method that returns action handlers to register. Additionally plugin should return:

• name (required)
• description (human readable)
• fbl version it guarantees to work
• tags

Improve plugin lookup to find fbl plugins installed in the same or any of parent dirs relative to the flow file.

Treat all files as patters.

E.g:

ctx:
  .:
    files:
      - *.yml

Add new action handler to invoke shell commands.

cmd:
  executable: string # path or name of executable
  args?: string[] # arguments passed to executable
  options?:
    stdout?: boolean # whether or not include stdout in the result
    stderr?: boolean # whether or not include stderr in the result
    code?: boolean # whether or not include stderr in the result
  context?:
   ctx?: string # path inside "ctx" to assign the result 
   secrets?: string # path inside "secrets" to assign the result 

Allow to specify any kind of meta information with action step. Reserve $ as a prefix.

E.g.:

version: 1.0.0
pipeline:
  $description: |-
    Detailed information about "ctx" action
  ctx: 
    '.':
      inline:
        option: value

There was an issue in past where prod dependency was in dev list and as a result all tests pass, but final FBL build was totally broken.

In some scenarios it might be handy to have direct access to node modules from template directly. E.g. $.require('os').platform() to check the platform, etc.

Both fbl CLI and attachment action handler should support flow reference from URL to download tarball:

fbl http://someservice.com/sample_0.1.3.tar.gz

Currently all Action Handlers that have "assign*To" options are only capable on saving to root of ctx or secrets. Instead - add ability to assign value to any nested object/array element with help of https://www.npmjs.com/package/jsonpath query.

If tarball has no index.yml in the root folder and has one and only one folder in the root of it - use index.yml from that subfolder.

Use https://github.com/shelljs/shelljs as a wrapper.

Need to support a way to package flows into tarballs. Both CLI and Attachment action handlers should support it.

Add ability to specify flow dependencies on fbl version and its plugins. Including native applications.

Add ability to register reporting records that should be printed to console at the end of execution.

Keeping an eye on intermediate logs might not be the best option for user, but looking into well formatted report in the end - is a nice option.

Also action handler "report" should be created. Suggested format:

report:
  title: string
  # if status matches one of 3 default ones - output will be colored in GREEN, RED or YELLOW
  status: SUCCESS | FAIL | SKIPPED | else
  # will not be part of the printed table, but may be used programmatically for future needs 
  payload: any 

If plugin is presented in system but is not loaded - try to load it automatically. Currently flow will just fail.

Replace behavior of "prompt" action to throw exception when interrupted.

Flow "requirements" block is not accepting semver. Looks like code just has invalid argument order passed to semver.verify function.

Similar to #113 we need to allow referencing node modules directly from the script.

All action handlers have description and examples inside metadata information. Use that to generate user documentation.

Currently if remote or flow inside the local tarball will be requested multiple times it will be re-downloaded / extracted as many times as it mentioned in the flow.

Documentation lacks sample flows that can help to understand how certain things can be achieved on a real world example.

We need to introduce build time EJS template processing, e.g. process entire yaml file upon load. Non-standard delimiter should be used for that. Proposal: $

So, the file may look like:

version: 1.0.0
pipeline:
  '--':
    <$ ctx.something.forEach(s => { $>
    - ctx:
        test_<$- s $>: 
          inline: <%- secrets.test_<$- s $> %>
    <$ }) $>

Also, both "build time" and "run time" delimiters should be customizable via CLI parameters.