Remove client side validation of Openwhisk flag limits

adobe / aio-cli-plugin-runtime

Adobe I/O Runtime plugin for the Adobe I/O CLI

https://www.adobe.io

Apache License 2.0

15 stars 31 forks source link

Remove client side validation of Openwhisk flag limits #317

Closed MichaelGoberling closed 1 year ago

MichaelGoberling commented 1 year ago

Description

Remove client side validation of Openwhisk flag limits. We shouldn't be doing client-side validation for these Openwhisk limits. The errors returned from the server are sufficient enough

Related Issue

Motivation and Context

Remove bloat and the need to track these values in multiple places

How Has This Been Tested?

Locally linked plugin and npm run test

Screenshots (if appropriate):

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

codecov[bot] commented 1 year ago

Codecov Report

Merging #317 (fc84b20) into master (3968c92) will not change coverage. The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #317   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           66        66           
  Lines         1749      1745    -4     
  Branches       367       369    +2     
=========================================
- Hits          1749      1745    -4

Files Changed	Coverage Δ
src/commands/runtime/action/list.js	`100.00% <ø> (ø)`
src/commands/runtime/activation/list.js	`100.00% <ø> (ø)`
src/commands/runtime/activation/logs.js	`100.00% <ø> (ø)`
src/commands/runtime/package/list.js	`100.00% <ø> (ø)`
src/commands/runtime/rule/list.js	`100.00% <ø> (ø)`
src/commands/runtime/trigger/list.js	`100.00% <ø> (ø)`
src/commands/runtime/action/create.js	`100.00% <100.00%> (ø)`

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

MichaelGoberling commented 1 year ago

@purplecabbage

Not sure, only reason I added the concurrency one was so I could set it for the provisioner blackbox action, since we can't manage blackbox actions with app.config.yaml yet. I don't use the others like memory or logsize personally

Yea I think the server responses seem fine, here's an example for concurrency. It shows exactly what flag failed and what the limit was, which I think is sufficient for users

Max exceeded

➜  runtime-memory-test git:(main) ✗ aio runtime action create test-1 --concurrency=5000 ./actions/generic/index.js 
 ›   Error: failed to create the action: the request content was malformed:
 ›   requirement failed: concurrency 5000 exceeds allowed threshold of 500 (400 Bad Request)
 ›    specify --verbose flag for more information

Min exceeded

➜  runtime-memory-test git:(main) ✗ aio runtime action create test-1 --concurrency=-1 ./actions/generic/index.js
 ›   Error: failed to create the action: the request content was malformed:
 ›   requirement failed: concurrency -1 below allowed threshold of 1 (400 Bad Request)
 ›    specify --verbose flag for more information