stoplightio/spectral-action

GitHub Action wrapper for Spectral - a JSON/YAML/OpenAPI/AsyncAPI/etc linter with custom rule support.

Spectral Linter Action

This action uses Spectral from Stoplight to lint your OpenAPI documents, or any other JSON/YAML files.

Usage

See action.yml

name: Run Spectral on Pull Requests

on:
  - pull_request

jobs:
  build:
    name: Run Spectral
    runs-on: ubuntu-latest
    steps:
      # Check out the repository
      - uses: actions/checkout@v3

      # Run Spectral
      - uses: stoplightio/spectral-action@latest
        with:
          file_glob: 'doc/api/*.yaml'

Inputs

• file_glob: Pattern describing the set of files to lint. Defaults to *.oas.{json,yml,yaml}. (Note: Pattern syntax is documented in the fast-glob package documentation)
• spectral_ruleset: Custom ruleset to load in Spectral. When unspecified, will try to load the default .spectral.yaml ruleset if it exists.

Configuration

Spectral Action will respect your Spectral Rulesets, which can be defined, extended, and overriden by placing .spectral.yml in the root of your repository.

However, if you'd like to simply use a core ruleset without additional configuration, create a .spectral.yml in you repository's root with only the contents: extends: ["spectral:{rulesetTagHere}"]

spectral-action's Issues

Node 16 is EOL

Node 16 went end-of-life on 2023-09-11. And github emits the following warning when using this action:

Run Spectral
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Can the Dockerfile be updated to use Node 20?

Invalid path for spectral errors when using a standalone schema

In this repository: https://github.com/ibrahimfw/ci-lint

Action shows error on the wrong file and the wrong line number (Its the end line instead of the start line).

CLI shows the correct error

Recent builds using action failing trying to build docker image

Today we started getting failures in our github actions builds using this action.
Failure encountered during the Build stoplightio/[email protected] step with the following message

Step 12/19 : RUN curl -sfL https://install.goreleaser.com/github.com/tj/node-prune.sh | bash
   ---> Using cache
   ---> 5dbcc9210831
  Step 13/19 : RUN ./bin/node-prune
   ---> Running in 1629fd948d2e
  /bin/sh: 1: ./bin/node-prune: not found
  The command '/bin/sh -c ./bin/node-prune' returned a non-zero code: 127

Seems like https://install.goreleaser.com/github.com/tj/node-prune.sh is not accessible anymore.

• Version used: 0.8.1

Linter gets stuck on invalid YAML files

Ran the linter action on an openapi spec with a the text of a git merge conflict committed and it was stuck continuously running, eventually hitting GitHub action rate limit

Context

Linter costing money to run private actions + producing false positives

Current Behavior

Linter fails on invalid files

Expected Behavior

Linter should fail fast on invalid files

Steps to Reproduce

1. Use the attached global.yml spec file which has a Git unresolved merge conflict in it.
2. Run a Spec Validate action on it
3. Job summary shows it succeeded with green checkmark, but actual result is an error:

   /!\ issues detected
   Error: You have exceeded a secondary rate limit. Please wait a few minutes before you try again.
   

Environment

• Version used: stoplightio/[email protected]
• Environment name and version (e.g. Chrome 39, node.js 5.4): GitHub Actions
• Operating System and version (desktop or mobile): ubuntu-latest

spec-and-logs.zip

Check run 'Lint (pull_request)' concluded with 'failure'

I am using APIOps in Github

In my current repo i have artifacts folder that contains multiple API folder , each api contain apiinformation.json, specification.yaml etc.

I want to implement spectral in my current repo and for that i have added spectral.yaml inside(.github/workflows), .spectral,json and action.yaml in root directory.

On pull request , github action run spectral.yaml and giving error
Check run 'Lint (pull_request)' concluded with 'failure'
Commit 40562d32617573afaa6d51e2698d5c0457c9994a has been annotated

Please help to solve this issue

Current Behavior

Expected Behavior

Possible Workaround/Solution

Steps to Reproduce

Environment

• Version used:
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):
• Link to your environment/workspace/project:

When a pull request is created spectral linter is not working

Describe the bug

When a pull request is created spectral linter is not working. showing the following error.

"required property "after" └─ cannot decode undefined, should be string"

its works fine when the pull request is updated with a new push.

To Reproduce

Workflow File:-
workflow file.zip

Expected behaviour

Spectral linter should work when the pull request is created.

Screenshots

Update spectral and other dependencies

Summary

Upgrade all libraries

Tasks

• Bump spectral to 5.8.0
• Bump octocat
• Bump others

Additional context

@philsturgeon @P0lip my colleague @astagi can look at this if you want!

Unable to extend ruleset from another private repo within my github organization

Unable to extend ruleset from another private repo within my github organization.

Context

In my ruleset.yaml, I am trying to extend from ruleset.yaml in another private repo within my github organization .

Current Behavior

Unable to load the ruleset. Getting error "Issue loading ruleset".

Expected Behavior

Should be able to load the ruleset from another private repo within my github organization.

Improperly defined required inputs in `action.yml`

Context

There are several inputs (repo_token, event_name) in the action.yml file that are denoted as required but have default values that are automatically populated by the GitHub Actions runner. These shouldn't be listed as required since they're getting flagged in GitHub Actions linters as missing parameters.

Current Behavior

When writing a GitHub Action workflow using this action, popular GitHub Actions extensions like this will flag the workflow as missing required parameters, even though the workflow runs just fine without them.

Expected Behavior

I should be able to use this in my workflow and only need to define the file_glob parameter.

Possible Workaround/Solution

Change this line and this line to be required: false.

spectral-action reports success due to "Error: You have exceeded a secondary rate limit."

The spectal-action is not failing when linting an OpenAPI document with a large (over 1000 errors). The issue appears to be that it is hitting "Error: You have exceeded a secondary rate limit".

Context

PRs with OpenAPI documents with a large amount of errors are passing the check. This makes the check useless in this case.

Current Behavior

PRs with OpenAPI documents with a large amount of errors are passing the check.

Expected Behavior

OpenAPI docs that should fail the PR check are passing.

Possible Workaround/Solution

I have not found a workaround yet. If the spectral-action hits this error it should report a failuire.

Steps to Reproduce

1. Use spectral-action to lint a document with over 1000 errors.

Environment

• Version used: 0.8.11
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):
• Link to your environment/workspace/project:

Default / Built-in ruleset behavior doesn't work as described

When trying to specify a core/provided ruleset, we did so before by specifying spectral-ruleset: "spectral:oas3". This stopped working because the ruleset is not being found in the github workspace (Separate issue potentially). Supposedly spectral-ruleset is an optional parameter, and if you don't use it, a built-in ruleset should be used. But getDefaultRulesetFile only searches the CWD for a default ruleset. If none are found, it errors out -- as opposed to using a built-in / core ruleset.

Context

Extra lint job, which pops up after job that contains the spectral action lint step, never ends:

This one's been going for like 3 days now.

Current Behavior

Aside from the extra lint job that never ends, the lint step in our build job ends in error, but is considered a success

When not specifying any spectral-ruleset you see:

When specifying a spectral-ruleset, attempting to use some existing core ruleset, you see this (Note: tried 'spectral:oas' in this run, but in others tried 'spectral:oas3' and 'oas3' -- same result each time)

Expected Behavior

1. When specifying some predefined spectral ruleset such as "spectral:oas3" it works as it did before (we had been on v0.5.5 for at least a year) and the openApiV3 ruleset is used.
2. When the optional ruleset parameter isn't included, some built-in ruleset is used as described in the README.

Possible Workaround/Solution

• Make getDefaultRulesetFile look for built-in rulesets if no ruleset is provided
• Make "spectral_ruleset" param values prefixed with 'spectral:' search stoplight-core (or stoplight-rulesets? However that works/used to work) for a matching ruleset with the suffixed tag.

Steps to Reproduce

Setup and run a job that looks like this:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Spectral Lint
        uses: stoplightio/[email protected]
        with:
          file_glob: ./public/api/*.yaml
          spectral_ruleset: "spectral:oas3"
          repo_token: ${{ secrets.GITHUB_TOKEN }}
.
.
.

Or like this:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Spectral Lint
        uses: stoplightio/[email protected]
        with:
          file_glob: ./public/api/*.yaml
          repo_token: ${{ secrets.GITHUB_TOKEN }}
.
.
.

Environment

• Version used: v0.8.2
• Environment name and version (e.g. Chrome 39, node.js 5.4): ubuntu-latest
• Operating System and version (desktop or mobile): desktop
• Link to your environment/workspace/project: private project

Cannot read property 'head' of undefined

Describe the bug

During a run of the Github Actions I get the following:

Run stoplightio/[email protected]
  with:
    file_glob: reference/v2/Index.yaml
    repo_token: ***
    event_name: pull_request
/usr/bin/docker run --name c27d31e4036e1dba5842deb4ae1a78b0ffbbb1_d82818 --label c27d31 --workdir /github/workspace --rm -e INPUT_FILE_GLOB -e INPUT_SPECTRAL_RULESET -e INPUT_REPO_TOKEN -e INPUT_EVENT_NAME -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/captains-log/captains-log":"/github/workspace" c27d31:e4036e1dba5842deb4ae1a78b0ffbbb1
(node:1) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'head' of undefined
    at extractSha (/action/dist/octokit.js:37:47)
    at /action/dist/octokit.js:53:34
    at /action/node_modules/fp-ts-contrib/lib/Do.js:31:96
    at Object.chain (/action/node_modules/fp-ts/lib/Either.js:474:57)
    at DoClass.bindL (/action/node_modules/fp-ts-contrib/lib/Do.js:31:43)
    at Object.exports.getRepositoryInfoFromEvent (/action/dist/octokit.js:53:6)
    at /action/dist/index.js:83:243
    at /action/node_modules/fp-ts/lib/EitherT.js:21:159
    at /action/node_modules/fp-ts/lib/Task.js:114:91
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

To Reproduce

main.yml

name: Run Spectral Linter on Pull Requests

on:
  - pull_request

jobs:
  build:
    name: Run Spectral Linter
    runs-on: ubuntu-latest
    steps:
      # Check out the repository
      - uses: actions/checkout@v2

      # Run Spectral
      - uses: stoplightio/[email protected]
        with:
          file_glob: 'reference/v2/Index.yaml'

Additional context
This also results in a 'pass' for the Github 'Check' which is surprising, I would expect an error on the command output to exit with 0 and show this as a failure.

Update yarn lock to pick up some bugfixes from dependencies

There was a bug in the spectral libraries described here. The bug was fixed earlier this year.

The dependency version that is present in the lock file is outdated so it doesn't include the new version of the spectral library which fixes this problem. As a result, users of the action can still hit the bug.

The solution is to regenerate the yarn lock file which will pick up the new version of the library so the bug will be fixed.

Master is broken, the action does not run

Describe the bug

Master looks broken as it does not run the Spectral checks (even though the checks themselves show ticks in the Actions view)

To Reproduce

Run the GitHub action (see https://github.com/stoplightio/spectral-action/actions/runs/208843869). Just using the default config, the action does not run.

The error is:

required property "after"
└─ cannot decode undefined, should be string

Expected behavior

The GitHub action should run the Spectral checks.

Bump spectral to 5.5

Summary

Bump spectral to 5.5

Add support for workflow triggers without a push or PR event

User Story Description

As a Software Developer,

I want to run the linter action without a push or pull request,

so I can define my own triggers/events for running the linter action.

Acceptance Criteria

• Linter runs correctly with a workflow_dispatch trigger on the current branch
• Linter runs correctly with a workflow_dispatch trigger against selected branch or commit sha (i.e. dispatch input)
• Linter runs correctly with a workflow_call trigger against a specified branch or commit sha parameter

Sprint Ready Checklist

• Acceptance criteria defined
• Team understands acceptance criteria
• Team has defined solution / steps to satisfy acceptance criteria
• Acceptance criteria is verifiable / testable
• External / 3rd Party dependencies identified

requesting an option to suppress "unrecognized-format"

User story.

As a spectral-action user, I can suppress unrecognized-format warnings, so that I can have flexibility in the linting reports.

Is your feature request related to a problem?

Currently, when you run the spectral GitHub action, we don't seem to have the option to suppress the unrecognized-format warning

Describe the solution you'd like

I would like some options similar to Spectral CLI --ignore-unknown-format that can be used in spectral-action as well to enable suppressing/ignoring the "unrecognized-format" warning

Additional context

None

Running the Spectrial action shows warnings but still passes

User story.

As a Developer I can do have warnings be reported as errors, so that the pipeline will fail so I know to fix them.

Is your feature request related to a problem?

Github actions only support a success and failure state, however spectral has support for warnings that get ignored.
Having an option to to have the warnings be reported as failures could be beneficial to cause the pipeline to fail to draw attention to the potential issue.

Describe the solution you'd like

The option to return an error status from an action when any warnings are present.

Additional context

Sample of the warnings being applied but the pipeline showing as passing

PR Check not showing the presents of any warnings

Build broken since latest changes

The build of the action is throwing an error

Context

Following the recent changes on the repository, the action does not build anymore.

Current Behavior

At the TS build step of the Dockerfile
tsc -p tsconfig.json
The build returns errors.

    Type 'TaskEither<Error, string[]>' is not assignable to type 'TaskEither<never, string[]>'.
      Type 'Error' is not assignable to type 'never'.
  src/index.ts(125,3): error TS2345: Argument of type 'IOEither<ProcessEnv, Error>' is not assignable to parameter of type 'IOEither<Error, Error>'.
    Type 'Dict<string>' is missing the following properties from type 'Error': name, message
  src/index.ts(125,45): error TS2345: Argument of type 'IO<{}>' is not assignable to parameter of type 'IO<Error>'.
    Type '{}' is missing the following properties from type 'Error': name, message
  src/index.ts(126,45): error TS2345: Argument of type 'Error' is not assignable to parameter of type 'ProcessEnv'.
    Index signature for type 'string' is missing in type 'Error'.
  src/index.ts(135,3): error TS2345: Argument of type '(ma: TaskEither<Error, { readonly config: { GITHUB_EVENT_PATH: string; INPUT_REPO_TOKEN: string; GITHUB_WORKSPACE: string; INPUT_FILE_GLOB: string; INPUT_EVENT_NAME: string; INPUT_SPECTRAL_RULESET: string; GITHUB_SERVER_URL: string; }; readonly repositoryInfo: RepositoryInfo; }>) => TaskEither<...>' is not assignable to parameter of type '(c: TaskEither<Error, { readonly config: { GITHUB_EVENT_PATH: string; INPUT_REPO_TOKEN: string; GITHUB_WORKSPACE: string; INPUT_FILE_GLOB: string; INPUT_EVENT_NAME: string; INPUT_SPECTRAL_RULESET: string; GITHUB_SERVER_URL: string; }; readonly repositoryInfo: RepositoryInfo; }>) => TaskEither<...>'.
    Type 'TaskEither<Error, { readonly config: { GITHUB_EVENT_PATH: string; INPUT_REPO_TOKEN: string; GITHUB_WORKSPACE: string; INPUT_FILE_GLOB: string; INPUT_EVENT_NAME: string; INPUT_SPECTRAL_RULESET: string; GITHUB_SERVER_URL: string; }; readonly repositoryInfo: RepositoryInfo; readonly octokit: { ...; } & ... 3 more ... &...' is not assignable to type 'TaskEither<never, { readonly config: { GITHUB_EVENT_PATH: string; INPUT_REPO_TOKEN: string; GITHUB_WORKSPACE: string; INPUT_FILE_GLOB: string; INPUT_EVENT_NAME: string; INPUT_SPECTRAL_RULESET: string; GITHUB_SERVER_URL: string; }; readonly repositoryInfo: RepositoryInfo; readonly octokit: { ...; } & ... 3 more ... &...'.
      Type 'Error' is not assignable to type 'never'.
  src/index.ts(169,1): error TS1[80](https://github.com/Unity-Technologies/unity-services-api-docs/actions/runs/7279457062/job/19836789286?pr=1296#step:3:80)46: 'program' is of type 'unknown'.
  src/index.ts(169,16): error TS7006: Parameter 'result' implicitly has an 'any' type.
  src/index.ts(173,18): error TS18046: 'e' is of type 'unknown'.

Those errors can be reproduced locally running yarn build.

Expected Behavior

The docker image builds correctly.

Possible Workaround/Solution

The regression is caused by this PR #656, likely a dependency issue. Reverting the merge commit solves the issue.

Introducing an automated test that the docker image builds could prevent this from happening.

Steps to Reproduce

Run yarn build
OR
Build docker image of the action

Environment

• Version used: latest
• Environment name and version (e.g. Chrome 39, node.js 5.4): N/A
• Operating System and version (desktop or mobile): N/A
• Link to your environment/workspace/project: N/A

Expose a parameter determining the minimum level that will trigger a build failure

By default, spectral-action will fail the check when at least one error has been discovered.
However, warnings for instance will generate annotations without failing the check.

Spectral exposes a flag that determine the minimum severity level that will trigger a failure.

Surfacing the parameter might be interesting to provide a better control to spectral-action users.

Add support for authorization against external schema registries

User Story Description

As a Software Developer,

I want to supply credentials for HTTP retrievals of absolute$ref URLs,

so I can access an external schema/component registry that requires authentication

Acceptance Criteria

• Linter successfully downloads JSON schema from an absolute $ref URL that requires HTTP basic authentication
• Linter successfully downloads a JSON schema from an absolute $ref URL that requires HTTP token (Bearer) authentication

Sprint Ready Checklist

• Acceptance criteria defined
• Team understands acceptance criteria
• Team has defined solution / steps to satisfy acceptance criteria
• Acceptance criteria is verifiable / testable
• External / 3rd Party dependencies identified

References point to developer account who no longer works for Stoplight

Context

Links outside of Stoplight's control

Current Behavior

The package JSON links to a developer account who no longer works at Stoplight.

• https://github.com/stoplightio/spectral-action/blob/master/package.json#L13-L23

Expected Behavior

Packaging and dependencies should be consistent and locked to an actively maintained project.

Possible Workaround/Solution

Update all references.

Steps to Reproduce

https://github.com/stoplightio/spectral-action/blob/master/package.json#L13-L23

Run spectral action for a pull_request fails but shows pass

Describe the bug

We use spectral to lint documents in our repo, however if someone opens a pull request the process fails with the following message:
Error: Resource not accessible by integration

Example see here:

However, the action passes and does not fail

https://github.com/bundesAPI/autobahn-api/runs/4684070400?check_suite_focus=true

To Reproduce

1. Create a pull request for a repo which uses the spectral action (v0.8.1)
2. Execute linting on the merge request
3. See error

Expected behavior

Linting runs on merge request branch and outputs linting errors and only passes if test is sucessful.

Additional context

Some research pointed towards the direction of missing permissions. I am wondering which permissions are required to perform the linting?

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (remove any that are not applicable):

• Github Actions

Host spectral in a pre-built container image

User story.

As a workflow user, I should not wait while spectral is being rebuilt into a Docker container for every run, so that I can enjoy super-fast job completion times.

Is your feature request related to a problem?

The action rebuilds and sets up Spectral in its entirety into a Docker image, with no caching seemingly occurring between job runs. This costs about 1.5 minutes for every job, not to mention taxing the public infrastructure of npm, Docker Hub, and possibly other web resources.

Describe the solution you'd like

Don't know the details of how actions can deploy containers, but I would imagine building a Docker image once per spectral update (or any change in the Dockerfile), pushing it to a registry (the one provided by GitHub, to keep things close?) and then pulling it in the action would speed up the jobs.

Error/warning messages are added to a completely different job

Context

Recently I have been working on this PR: hse-project/hse#316. During my work, I have created an OpenAPI document at https://github.com/hse-project/hse/blob/tristan957/rest/docs/openapi.yaml. I thought I would add some linting for the file, and this action was the best one I could find (nice job by the way, really useful, also installed the VSCode extension). The GitHub Action workflow is defined at https://github.com/hse-project/hse/blob/tristan957/rest/.github/workflows/openapi.yaml. You can see the workflow's name is "OpenAPI" and the singular job's name is "lint". During the course of my development, I have discovered this interesting behavior from this action.

Here is my spectral config file: https://github.com/hse-project/hse/blob/tristan957/rest/.spectral.yaml

Current Behavior

What is currently happening is that the messages that this action generates get added to a job that doesn't exist.

Note the uppercase "Lint". In my multiple revisions of this PR, I have also seen this job get added to other workflows that aren't the "OpenAPI" workflow described above.

https://github.com/hse-project/hse/runs/7460788923

Note that there are currently no issues with the file, so no messages were added.

Edit:

Expected Behavior

I would have expected the messages to be included in the job that actually generates them.

Steps to Reproduce

1. Create workflow to run spectral
2. Run the workflow
3. Denote job that was created that hasn't previously existed

This seems partially related to #506. At least that also mentions a "Lint" job.

Leverage GitHub action ProblemMatchers

spectral-action currently relies on octokit to manually create annotations.

This doesn't seem aligned with the future (cf. actions/toolkit#74 (comment))

Relevant:

• actions/toolkit#56
• https://github.com/actions/toolkit/pull/198/files

Erro running in branches and pull requests

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

1. In my repository https://github.com/luankevinferreira/areadesenvolvedor I use the action with the following definition:

name: Stoplight

on:
  push:
    branches: [ '*' ]
  pull_request:
    branches: [ '*' ]

jobs:
  lint:
    name: Run Spectral
    runs-on: ubuntu-latest
    steps:
      # Check out the repository
      - uses: actions/checkout@v2

      # Run Spectral
      - name: Spectral Linting
        uses: stoplightio/[email protected]
        with:
          file_glob: 'documentation/source/swagger/*.yaml'

In branches executions and pull requests, I see the following error message:

(node:1) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'head' of undefined at extractSha (/action/dist/octokit.js:37:47) at /action/dist/octokit.js:53:34 at /action/node_modules/fp-ts-contrib/lib/Do.js:31:96 at Object.chain (/action/node_modules/fp-ts/lib/Either.js:474:57) at DoClass.bindL (/action/node_modules/fp-ts-contrib/lib/Do.js:31:43) at Object.exports.getRepositoryInfoFromEvent (/action/dist/octokit.js:53:6) at /action/dist/index.js:83:243 at /action/node_modules/fp-ts/lib/EitherT.js:21:159 at /action/node_modules/fp-ts/lib/Task.js:114:91 (node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Expected behavior

Run the action in branches and pull requests properly

Regression of #506

Regression of #506 in latest commit

Context

Current Behavior

Expected Behavior

Possible Workaround/Solution

Steps to Reproduce

Environment

• Version used:
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):
• Link to your environment/workspace/project:

Error when linting produces more than 50 annotations

Describe the bug

Running this action against a large OAS yaml file, and it gets the following error:

No more than 50 items are allowed; 77 were supplied.

It would seem that this is a result of the limit on Annotations to be added in a single API request, as per https://developer.github.com/v3/checks/runs/

The Checks API limits the number of annotations to a maximum of 50 per API request. To create more than 50 annotations, you have to make multiple requests to the Update a check run endpoint. Each time you update the check run, annotations are appended to the list of annotations that already exist for the check run. For details about how you can view annotations on GitHub, see "About status checks".

To Reproduce

Setup this action to run for every new pull request.
Create a new yaml file with more than 50 linting errors, and create a new pull request for it.

Expected behavior

This action should post back annotations to the action for every linting error, regardless of the count.

Include the /dist directory in the release instead of building the action in docker every time it runs

Context

Every time the actions runs there's a docker build step:

Build stoplightio/spectral-action@latest time: 1m 12s

That takes > 1 minute on the github ubuntu-latest (currently Ubuntu 22.04.1 LTS) image.
The actual validation of our openapi spec takes just under a second.

Current Behavior

The action is setup as a docker container action that builds the action every time it is executed.

Expected Behavior

• The action is setup as a javascript action, with the /dist directory checked in and part of the release, so that there is no build step on action run.

• Runtime is only spent on the actual validation.

• As in the typescript action sample implementation a check-dist.yml workflow verifies that the checked in /dist matches expected build

Assumptions

• All dependencies are pure typescript/javascript that can be precompiled and run on the github actions node.js version - there are no runtime dependencies that require executing in a docker container.
  • From a glance at the dependencies in the package.json, this seems to be true.

No relevant error information

Summary
Show the exact error that caused the action failure

Example
All it says is '1 issue detected':

When I run the linter locally, I get error oas3-schema 'requestBody' property should have required property '$ref'. This is an issue in of itself that I documented here: stoplightio/spectral#1072 (comment).

Extra job "Lint (push)" remains in progress

Describe the bug

Using this action we get an extra job named "Lint (push)" that never completes. This marks checks on PRs as not completed. See also screenshot

Along with our defined job "Run Spectral" an extra job "Lint (push)" appears on builds that never completes.

To Reproduce

We use the same configuration that's included in project readme.

Environment (remove any that are not applicable):

• Library version: 0.7.0 and 0.7.1