listendev/action

Run listen.dev natively in CI using GitHub actions

action's Issues

Implement caching

Describe the feature or problem you’d like to solve

Currently, this action downloads the lstn binary every time it executes.

Proposed solution

We should implement caching, as to avoid having to download it every time wasting user's time and resources.

Additional context

NONE

Revise marketplace listing

Description

Revise branding and messaging for the GitHub marketplace listing based on ongoing iteration.

Proposed solution

Revised name, description and branding fields in action.yml

Additional context

Waiting to hear back from GitHub regarding custom branding.

Setup workflow to automatically update configuration files from actions/reusable-workflows

Integration self tests

We wanna test the action on its own repository.

Do not run self tests on push events (only on pull requests)

Describe the bug

The lstn CLI doesn't understand yet if it's running on pull requests or not. So the reporters break when running on push events (ie., on the main branch).

Expected vs actual behavior

To do not run on the main branch.

Logs

Create API to install `lstn` in the GitHub action runners

Describe the feature or problem you’d like to solve

To use https://github.com/listendev/lstn we must install it in the GitHub action runner.

Proposed solution

Write a Typescript function that looks for its release, given a tag.

If found, it then downloads the correct archive (respecting the platform and architecture of the runner) if it exists.

Additional context

NONE

Execute `lstn` via the GitHub Action execution toolkit

Describe the feature or problem you’d like to solve

Once downloaded, we wanna execute lstn.

Proposed solution

GitHub provides a TypeScript toolkit to do a few things, for example, execute a binary.

Additional context

NONE

Setup CodeQL workflow

Run integration tests on darwin too

Setup linting and formatting

Setup workflow to check the dist/ directory is up to date

Release workflow

Create the testing CI workflow

Update eslint configuration

To match the configuration the reusable-workflows repo uses.

Create action input to let the users provide additional lstn flags

Describe the feature or problem you’d like to solve

We wanna have a way to provide to the lstn invocation additional flags. This is gonna be useful for power users.

Proposed solution

Create another action input named lstn_flags (string).
Then split it into an array and pass to the invocation.

Additional context

NONE

Call the `lstn scan`

Describe the feature or problem you’d like to solve

Currently this action just calls lstn --help. We wanna call lstn scan and provide it with all the correct options (reporters, etc.).

Proposed solution

I propose giving the action a reporter input, grabbing the GitHub info (PR number, etc.) and call the scan child command.

Additional context

NONE

Build the action in a single Javascript file

Describe the feature or problem you’d like to solve

We need to distribute the action as a single JavaScript artifact.

Proposed solution

To do so I propose to create a build npm script that:

1. compiles the TypeScript in Javascript
2. packages the resulting Javascript and all of its deps with @vercel/ncc

Additional context

NONE

Define the action YAML

Describe the feature or problem you’d like to solve

We need to bootstrap the action!

Proposed solution

Nothing special. Just create the action.yaml file.

Additional context

NONE

Wrong commandline arguments parsing in the lstn_flags property

Describe the bug

Let's assume users wanna use the action in their CI systems, and they only wanna see the listenev bot commenting with high severity alerts on their pull requests because they wanna reduce the noise.

So their are probably going to write a YAML definition of a GitHub action workflow with something like this in their repo:

steps:
  - uses: listendev/[email protected]
    with:
      lstn: "v0.2.2"
      reporter: "gh-pull-comment"
      lstn_flags: "--select '(@.severity == \"high\")' ...other flags..."

Right? Good!

Well, the action is gonna download lstn v0.9.0 containing the server-side JSONPath filtering feature (ie., --select flag)...

The problem is that the action breaks while executing the YAML definition above! 🚨

Why so?

Because the lstn_flags is a string while the GitHub actions core engine wants an array of command arguments.

This means that the CLI will actually run with something like lstn X --select X '(@.severity X == X \"high\")' where every X mark I used is to indicate a new element of the command arguments list! And this is clearly a wrong command line that can never work! To explain it in programming terms, the lstn binary will be given an array of arguments like this ["--select", "'(@.severity", "==", "\"high\")'"] rather than the correct one ["--select", "(@.severity == \"high\")"] (2 arguments, flag, and its value).

Not to mention that for some flags (like --select|-s but also --jq|-q) we may need proper quotes quoting, etc.

I have some possible solutions:

1. One option is to write a very complicated regex (or parser) for command arguments parsing to convert them from string to a proper arguments list.
2. Another option would be to replicate all the CLI flags one by one in the action.

Some words on them now.

Solution 2

Solution 2 means replicating what we have in the lstn CLI regarding the command line parsing (arguments, correct types, validation), etc.

I didn't do this at the time because it also means to have a huge action.yml and it would make the usage of our action painful for users.

Just think how time-wasting is to replicate all the CLI logic in TypeScript.

Then think about how to keep it always in sync with the different CLI versions, and then think about how painful would be to keep it documented, or to debug it. At each new lstn release we will be stuck again in this hell loop.

Also, I can't think right now of a simple way to handle different sets of flags/parameters for different commands (lstn scan vs lstn in vs lstn to have different flags/features).

This was why I chose (at the time) to make the action work as a proxy to the lstn invocation and use the validation, error handling, etc. of our beautiful Go CLI.

Solution 1

Solution 1 sounds scary and it'll probably be so.

But it would keep our GitHub action simple and not a TypeScript boilerplate replicating the Go logic we have in the CLI for the command line argument parsing and so on.

Once we parse correctly the lstn_flags we will not have to come back at this issue for new CLI flags or features, just to mention one of the many pros this approach has.

Bonus: Solution 3

Read more in this other issue I've opened.

👉 #43

Expected vs actual behavior

Expecting the lstn_flags to get properly parsed and passed down to the lstn CLI correctly.

Logs

NONE

Fetch Github context automatically

Describe the feature or problem you’d like to solve

The lstn CLI has now the ability to understand whether it's running in a GitHub action or not.

When it detects that it's running in a GitHub Action, it automatically fetches the pull request ID (number), the repository name, etc.

Proposed solution

Use the built-in detection feature rather than explicitly retrieving the GitHub context in the action.

Additional context

NONE

Create a `select` input

Describe the feature or problem you’d like to solve

Following up from #42.

We may have (and we have) some lstn flags (like the JSONPath filtering one introduced in v0.9.0 - ie., --select or -s) that:

• are important features we wanna expose as first-class action inputs
• requires complex values (with whitespace, operators, single or double quotes, quoted strings).

It can become increasingly difficult to manage their values parsing in the lstn_flags input.

I propose to add a new select input/field to the action.

Proposed solution

Users can have access to the lstn selection feature in an easier way if we implement this.

Also, it wouldn't need the parsing of the select value (string).

Additional context

NONE

Support monorepos

Describe the feature or problem you’d like to solve

Hi team! My company is trying out the GitHub action right now and I've added it to one of our repos. So far so good, besides one thing I'm noticing which would be helpful for this particular repo.

This repo I'm adding it to is a monorepo, and when I try running the action at the root directory, it'll just look at the subset of packages defined in that top-level package.json. I tried solving that by just running the action multiple times in different working directories, which did scan everything, but then the PR comment that's generated gets overwritten for each one. Hopefully this representative example of my action makes it clearer:

steps:
  - name: Check out repo
    uses: actions/checkout@v3

  - name: Run listen.dev on top-level packages
    uses: listendev/[email protected]

  # Creates a new PR comment, overwriting the first one
  - name: Run listen.dev on subproject 1
    uses: listendev/[email protected]
    with:
      workdir: apps/sub1

  # Creates a new PR comment, overwriting the second one
  - name: Run listen.dev on subproject 2
    uses: listendev/[email protected]
    with:
      workdir: apps/sub2

Proposed solution

The ideal solution IMO would be being able to run the action at the root and have it intelligently parse the subproject package.jsons, putting the full report into one comment.

Alternatively, as an easier solution, maybe an option could be added so that each run of the action could be commented separately, but still be updated on new PR pushes? An action I use elsewhere in the project for commenting on PRs has something like that called a comment_tag: https://github.com/thollander/actions-comment-pull-request#update-a-comment