Create OIH Compliant Action 'Upsert File'

[hannah-bulmer]

OIH Standard

SFTP should have an action Upsert File that would allow for new file content to replace that in an existing file, or for a file to be created with such content if one doesn't exist.

Since files are the only object we are interacting with, it probably does not make sense to include any config fields for this action.

Metadata fields would include

• full file name of the file to write (in SFTP)
• content to post to the file (URL from Stewart)

We will leave it to users to write JSONata expressions that evaluate to file names with the correct extensions.

[jhorbulyk]

My Notes:

• We could use the flag SSH_FXF_OPEN_OR_CREATE when opening files with SSH_FXF_BLOCK_WRITE.
• In a future iteration, we might add an append option with flag SSH_FXF_APPEND_DATA_ATOMIC

[A3a3e1]

DoD

Component development prerequisites:

• [ ] All the branches if the repo should be checked (merged/deleted if possible) before starting development
• [ ] Development team has all needed requirements
• [ ] Access to the needed service with all needed permissions is granted
• [ ] No open tasks that could block Component development process
• [ ] The E.io’s GitHub repository must be checked if there is another implementation of the component under development. If it exists, new repository should not be created
• [ ] Component architecture should be discussed and approved before start coding
• [ ] New component GIT repo preconditions:
  • repo type (private/public)
  • license type
• [ ] Component deployment preconditions:
  • Where to deploy (app.elastic.io etc..)
  • Component's access level on each installation that component must be deployed on\

Development:

• [ ] Code is written and formatted in accordance with the Styling guide
• [ ] Code (incl. configs, test samples, environment variables etc.) MUST NOT contain any sensitive data like passwords, tokens, API keys etc.
• [ ] Component logs does not contain any sensitive data (credentials, input/output requests, Environment variables)
• [ ] Code is covered with unit tests
• [ ] Component code is covered with integration tests (optional)
• [ ] Triggers/actions comply with OIH patterns
• [ ] Documentation (README.md file in the Github) is 100% ready
• [ ] Changelogs (CHANGELOG.md) are created/updated
• [ ] package.json or build.gradle is updated:
  • Component's version is updated according to Semantic Versioning 2.0.0
• [ ] Component should be dockerised, add: "buildType":"docker" line into component.json
• [ ] CI is set up
• [ ] All development branches are reviewed

After QA:

• [ ] All development branches are merged into master branch
• [ ] Sprint review preparation is finished (demo flow is built)

QA:

• [ ] Test cases for the component are ready at the TestRail
• [ ] Functional testing is finished
• [ ] Regression testing is finished (optional)
• [ ] Component is deployed to the production stage (app.elastic.io) and/or other required stage
  • Component has a proper access level
  • Required Environment Variables are set
  • Smoke test is finished
• [ ] Release notes is done
• [ ] Component Roadmap is updated
• [ ] Component spreadsheet is updated

[A3a3e1]

Pls use https://github.com/elasticio/oih-standard-library

[A3a3e1]

Only review and test action are included in estimation.