Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update test fn-render/multiple-fnconfig #1839

Merged
merged 1 commit into from
May 3, 2021

Conversation

natasha41575
Copy link
Contributor

This test case passes so we don't need to skip it

@natasha41575 natasha41575 added this to In Review in kpt kanban board via automation Apr 29, 2021
@mikebz
Copy link
Contributor

mikebz commented Apr 29, 2021

LGTM

@natasha41575 natasha41575 requested a review from droot April 30, 2021 21:38
Copy link
Contributor

@droot droot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving this to enable the testcase, but I would really like the error message improvement as a followup PR.

@@ -13,4 +13,4 @@
# limitations under the License.

exitCode: 1
skip: true # TODO: enable once the testcase is supported
stdErr: "following fields are mutually exclusive: 'config', 'configMap', 'configPath'. Got \"configPath, configMap\""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should address the following in a followup PR:

Improve the error message to fit our error-style ?

Wondering how to convey oneOf fields in more user friendly way: One option could be:
"function config must have only config or configMap or configPath input"

We also need the pkg and function involved in this error to make it really actionable. I have some ideas on introducing a new validationError, let have a chat offline about that.

Copy link
Contributor

@frankfarzan frankfarzan May 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, every message needs to meet go/kpt-errors-style-guide.

In this case, I see the following issues:

  1. We should tell users why they CAN do. They can specify only one of the 3 fields.
  2. Quotation issue: "configPath, configMap" (The user is not providing a string with value of ConfigPath, configMap

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment about this to #1557; let me know if there should be a separate issue instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a specific error message I think we should create a separate issue otherwise #1557 will be longer and longer.

@natasha41575 natasha41575 merged commit 750401c into kptdev:next May 3, 2021
kpt kanban board automation moved this from In Review to Done May 3, 2021
frankfarzan pushed a commit to frankfarzan/kpt that referenced this pull request Jun 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants