Version:

Version 0.3.8

What happened:

We are trying to use the entity validator in an Azure DevOps build and are hitting this error:

/usr/bin/env: 'node\r': No such file or directory

The call we are making is: validate-entity 'catalog/**/*.yaml' -q

We store all our catalog entities as subfolders under catalog. This works fine on a local machine but fails as soon as it runs in the CI.

Expected behavior:

It should validate the entities without error.

Additional Information:

I'm honestly just looking for some advice as to what we might be doing wrong. Thanks for making this tool!

Describe Request:

Instead of requiring users to manually specify the list of Backstage YAML files, we should check all YAML files for apiVersion: backstage.io/v1alpha1 and syntax check them if they have changed.

This would make it easier to automatically lint Backstage metadata files when running the validator as a hosted check solution.

This is new to me, so it is possible that I have misunderstood something, but I believe that this line should not be here: https://github.com/RoadieHQ/backstage-entity-validator/blob/68841ee4a3cbb89ca54c58300ab55dc2807fd275/src/schemas/annotations.schema.json#L16

I've been seeing this error when I run this validator:

strict mode: missing type "array" for keyword "uniqueItems" at "Entity metadata annotations#/properties/metadata/properties/annotations" (strictTypes)

Based on my read of the json schema spec, uniqueItems should only be present for array types, not objects - relevant doc

Hi there,

I was having a look at the entity validator and I notice that it points to a library hosted on NPM here: https://www.npmjs.com/package/@roadiehq/roadie-backstage-entity-validator

The actual source code doesn't seem to be available from what I can tell though unless I'm missing something?

I can understand that RoadieHQ may want to keep it closed source as it's useful for their business but just wanted to confirm that I haven't overlooked another repo 🙂

Thanks!

Version:

0.3.7

What happened:

validator fails with:

Your catalog file(s) is/are not valid:

There was an error verifying entity-templates/catalog-info-2.yml:
TypeError: <root> should have required property 'spec' - missingProperty: spec

Expected behavior:

the validator should succeed (no errors should arise). This should happen because of these backstage docs which show spec as optional

Additional Information:

here is a sample Location (catalog-info.yaml)

apiVersion: backstage.io/v1alpha1
kind: Location
metadata:
  name: todo-example-project

a fix was to add a dummy spec:

apiVersion: backstage.io/v1alpha1
kind: Location
metadata:
  name: todo-example-project
spec:
  type: dummy

Problem

The tool does not support validating multiple files at once.

Solution

Introduce a CLI that makes it possible to validate several files at once.

Notes

We first tried to wrap the invocation of this tool in a shell script, calling it once per file we needed to validate. With ~400 files it took ~6m30s to complete which felt too long.

We speculated that the bulk of the time being spent during a single execution was in the Ajv schema-validation compile phase. We hacked up a script to validate our suspicion and indeed found it to be true. We were able to validate ~400 files in ~6s; with the schema-validation compile happening once (It looks like Ajv caches compilation; calling it a second time is pretty fast).

The choice to use minimist was based on introducing the least number of dependencies.

There are two ways to provide files to validate:

1. via CLI arguments
2. via STDIN

We chose not to include a file-finder/globber as we felt that role was best left to other tools. e.g. via shell globbing validate-entity catalog/**/*.yaml, or piped input find ./catalog/ -name '*.yaml' -or -name '*.yml' | validate-entity -i

Validating several files at once produces a lot of output. To that end, a quiet option was introduced to control the verbosity of existing logging statements.

Care was taken to not introduce changes to the existing CLI interface which expects a single file to validate.

CLI usage:

❯ node src/index.js -h
Usage: validate-entity [OPTION] [FILE]

Validates Backstage entity definition files.  Files may be specified as
arguments or via STDIN, one per line.

OPTION:
-h  display help
-q  minimal output while validating entities
-i  validate files provided over standard input

Problem

Some links that we use do not have a trailing slash at the end. Adding the trailing slash to these URLs results in a 404.

Solution

Remove the required trailing slash at the end of the source-location validator for non-directory locations. This allows us to use locations like url:http://some/where/else.

Should fix https://github.com/RoadieHQ/backstage-entity-validator/issues/35 When I ran the file command on src/index.js I got the following error:

backstage-entity-validator/src/index.js: C source, ASCII text, with CRLF line terminators

I ran dos2unix tool on the index.js file and on a build it regenerated the changed files.

Use dist/index.js as entrypoint for the program. It cannot be overwritten in the publishConfig

Describe Request:

A good way to represent a Monorepo in Backstage is to have a Location file at the root of the repo and include links in it to point to other files in the subdirectories where the metadata actually lives.

The validator should follow the links in these Location files to discover and validate the metadata in the subdirectories.

As outlined in #15, it is not possible to validate multiple files using the GitHub Action. This Pull Requests add support for the following scenarios

Validate multiple files separated by comma

Actions do not support arrays, only string values see. This is a workaround to support multiple files passed in from a single input.

- uses:  RoadieHQ/[email protected]
  with:
    path: 'catalog-info-1.yaml,catalog-info-2.yaml,catalog-info-3.yaml'

Validate multiple files using a glob

Using a glob allows you to define a pattern and expand the input. In the example below, all files matching this pattern will be returns.

- uses:  RoadieHQ/[email protected]
  with:
    path: 'catalog-info-*.yaml,services/**/*/catalog-info.yaml'

General globbing support

Even the terminal expands glob patterns, in certain situations this does not work e.g. when passing a list of files using STDIN. With this change globs are supported in scenarios.

Hi, thank you so much for creating this validator. I've noticed that the input (in a Github Action context) can be only a single path. In our monorepo context this doesn't scale very well. Ideally I would like to be able to define a glob or pass in a list of files like

- uses: RoadieHQ/backstage-entity-validator@@0.3.0
  with:
    path: './a/service-a.yaml ./b/service-b.yaml ./c/service-c.yaml'

or as a glob

- uses: RoadieHQ/backstage-entity-validator@@0.3.0
  with:
    path: './*/service-*.yaml'

Would you accept such a contribution?

Bumps minimatch from 3.0.4 to 3.1.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe Request:

Github has announced they will be deprecation of Node 12 in actions and recommending upgrading to use Node 16. Using this action currently results in the following warning.

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16

Supporting Documentation Links:

https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/

Bumps @actions/core from 1.2.7 to 1.9.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Version:

0.4.2

What happened:

The usage examples for the Circle Orb suggest a job is provided by the orb, when it is in fact a command. This means the examples don't actually work.

Instead of doing this:

description: >
  Sample catalog-info.yaml validation
usage:
  version: 2.1
  orbs:
    entity-validator: "roadiehq/[email protected]"
  workflows:
    use-entity-validator:
      jobs:
        - entity-validator/validate:
            path: catalog-info.yaml

You actually need something like this:

description: >
  Sample catalog-info.yaml validation
usage:
  version: 2.1
  orbs:
    entity-validator: "roadiehq/[email protected]"
   
jobs:
  validate:
    docker:
      - image: cimg/node:lts
    steps:
      - checkout
      - entity-validator/validate:
          path: catalog-info.yaml
      
workflows:
  use-entity-validator:
    jobs:
      - validate

Expected behavior:

Whilst this could just be a documentation update, ideally the orb would provide both a job and command. The job would minimise the amount of config required to get something up and running quickly, and also mean the examples would work

Additional Information:

I'm happy to make a PR with the changes to add a job, but I'm a bit nervous because the build doesn't actually test the orb is working (https://github.com/RoadieHQ/backstage-entity-validator/issues/46)

What happened:

I was looking to make some enhancements to the Circle CI Orb, to make it a little easier to use however on looking at the build I realise that the Orb tests defined in the integration-test-1 job are never invoked

Expected behavior:

The CircleCI build should run the integration tests to verify the Orb works before publishing.

Additional Information:

Due to limitations in Orb testing it might not be possible to test out unhappy paths, but it should be straightforward to run through the happy path examples.

Looks like this orb is based on a slightly older orb template, but you can see how the tests should be invoked by looking at the template here