api-linter icon indicating copy to clipboard operation
api-linter copied to clipboard

YAML output issues

Open bufdev opened this issue 6 years ago • 6 comments

Similar to #306, using same commit of both api-linter and googleapis/googleapis.

Issues:

  • Arrays elements printed for files with no problems.
  • I think this invalid YAML but might be wrong - string values printed across multiple lines with various quoting, for example:
 - message: Use the `google.api.field_behavior` annotation instead of " Required.
      CLDR region code of the country/region of the address. This" in the leading
      comments. For example, `string name = 1 [(google.api.field_behavior) = REQUIRED];`.

Unrelated to YAML, but probably not worth filing another issue: api-linter exits with code 0 if there are lint issues. This may be by design though.

$ api-linter google/type/*.proto
- file_path: google/type/calendar_period.proto
  problems: []
- file_path: google/type/color.proto
  problems: []
- file_path: google/type/date.proto
  problems: []
- file_path: google/type/dayofweek.proto
  problems: []
- file_path: google/type/expr.proto
  problems: []
- file_path: google/type/fraction.proto
  problems: []
- file_path: google/type/latlng.proto
  problems: []
- file_path: google/type/money.proto
  problems:
  - message: Fields representing timestamps should use `google.protobuf.Timestamp`.
    location:
      start_position:
        line_number: 43
        column_number: 3
      end_position:
        line_number: 43
        column_number: 19
    rule_id: core::0142::time-field-type
    rule_doc_uri: https://googleapis.github.io/api-linter/rules/core/0142-time-field-type.html
- file_path: google/type/postal_address.proto
  problems:
  - message: Use the `google.api.field_behavior` annotation instead of " Required.
      CLDR region code of the country/region of the address. This" in the leading
      comments. For example, `string name = 1 [(google.api.field_behavior) = REQUIRED];`.
    location:
      start_position:
        line_number: 52
        column_number: 3
      end_position:
        line_number: 52
        column_number: 26
    rule_id: core::0203::required
    rule_doc_uri: https://googleapis.github.io/api-linter/rules/core/0203-required.html
- file_path: google/type/quaternion.proto
  problems: []
- file_path: google/type/timeofday.proto
  problems:
  - message: Fields representing timestamps should use `google.protobuf.Timestamp`.
    location:
      start_position:
        line_number: 41
        column_number: 3
      end_position:
        line_number: 41
        column_number: 21
    rule_id: core::0142::time-field-type
    rule_doc_uri: https://googleapis.github.io/api-linter/rules/core/0142-time-field-type.html
  - message: Fields representing timestamps should use `google.protobuf.Timestamp`.
    location:
      start_position:
        line_number: 44
        column_number: 3
      end_position:
        line_number: 44
        column_number: 19
    rule_id: core::0142::time-field-type
    rule_doc_uri: https://googleapis.github.io/api-linter/rules/core/0142-time-field-type.html

bufdev avatar Nov 05 '19 21:11 bufdev

Personally, I think the linter should exit 1 if it finds errors, and 0 if it finds only warnings.

lukesneeringer avatar Nov 08 '19 04:11 lukesneeringer

Also ideally the tool will have some flag like gcc's -Werror to allowing making some warnings into errors

rcleveng avatar May 24 '20 17:05 rcleveng

We have that already!

lukesneeringer avatar Jun 19 '20 00:06 lukesneeringer

Is there anything actionable here?

apasel422 avatar Oct 21 '20 18:10 apasel422

The invalid YAML is an issue. For multi-line strings, it should be:

  - message: >
      Use the `google.api.field_behavior` annotation instead of " Required.
      CLDR region code of the country/region of the address. This" in the leading
      comments. For example, `string name = 1 [(google.api.field_behavior) = REQUIRED];`.

The real reason this particular one is happening is because we are preserving a newline from input, but regardless, we should detect \n and do the right thing.

This also might be an issue in whatever YAML output dependency we are using.

lukesneeringer avatar Oct 27 '20 19:10 lukesneeringer

Yeah, I'm surprised that the tests for https://github.com/go-yaml/yaml seem a bit limited in coverage of string encoding.

apasel422 avatar Dec 16 '20 17:12 apasel422