feat: initial release

[kettanaito]

• Migrated pull request from feat: add github action artillery#1962

Users can now adopt Artillery easier in their GitHub workflows by using our action:

- name: Load tests
  uses: artilleryio/action-run@v1
  with:
    test: ./prod.yml
    output: ./my-report.json

Changes

• Adds the actual action implementation (depending on our Docker container).
• Adds an automated release and tagging pipelines using Release Please.
• Adds a nice README with minimal documentation and a few usage examples.

Roadmap

• Skip the CHANGELOG generation and treat GitHub Releases as the changelog.

[kettanaito]

Disabling changelog

I researched this and found no existing means to disable the CHANGELOG.md generation by Release Please. Neither the GitHub Action nor the underlying CLI provide a flag to achieve that behavior.

I've opened a feature proposal to add it googleapis/release-please#2007.

[bernardobridge]

Nice work on this! Just have a difference of opinion on maybe exposing an additional first flag, but LGTM otherwise

[hassy]

What's the difference between this and the output option?

[kettanaito]

This one is not the option you provide to the action but what output the action provides you. In other words, regardless of how you run Artillery as a part of your workflow, you can always access the test run report under ${{ steps[id].outputs.report }} (a path to the report file on the remote machine).

This is pretty handy as an output because it allows devs to manipulate the report easier, using the standard GitHub Actions' output API. For example, they can upload the report as an artifact or feed it to another step by referencing the output.

[hassy]

Is there a way to default to using the latest Docker image, but allow overrides explicitly? So that users don't have to remember to always include container?

[kettanaito]

@hassy, I will look more into it. So far, the closest thing for a custom action to specify a Docker container is creating a Docker container action. Based on the resources I read, it looks like the container will only be used to run the action (?) but not the entire workflow, so it doesn't act as an override for the job-level container field.

I will try to find some examples of this and see if we can use it in any way to make the container setup easier for the users.

[kettanaito]

@hassy, I've played around with the Docker GitHub Actions and found a way for us to use our container as a part of our action so the developers don't have to specify it in their workflows anymore.

• feat: use a docker action #2

This change also means that we don't keep any dependencies and use an entrypoint.sh script in the container to run the CLI as a part of this action. I've also added the tests for the action that take it from the repo and embed it into a workflow, then validate the run and the action's output.

[bernardobridge]

LGTM ! Cool to see you ended up with the Docker Container Action after all. Now we know about both ways, so if/when we do ship a NodeJS API, we can revisit this easily if we want 👍

[kettanaito]

@bernardobridge, exactly! Since the Docker container usage became an implementation detail, we can manage it internally without introducing any breaking changes to the consumers.

[kettanaito]

Documenting the new action in here https://github.com/artilleryio/docs/pull/21