stoat-dev / stoat-action Goto Github PK

see #115 (comment) and the reply

We now provide the merged config input to a sandbox vm for JS which is detected when a the template file has a .js extension and process the console logs as the markdown displayed in the Github comment.

We also provide the config input to Jinja2 for .jinja2 extensions.

We just need to document that usage so people can use it.

When baseline does not exist, compare the image in the PR with the one from the default branch.

Relate to #96.

https://github.com/stoat-dev/stoat-action/actions/runs/3660320900/jobs/6187319317

It may be beneficial to make the overall comment shorter by using two columns:

Easy and customizable dashboards for your build system. Learn more about Stoat ↗︎

Static Hosting	Job Runtime
Name Commit Status Documentation 4862dc6 ✅ CLI Test Coverage 50040c1 ✅ Action Test Coverage f2b1008 ✅

I'd be curious what everyone thinks about this vs the current default.

Release process:

• Bump version
• Tag the head commit with the latest version
• Update latest, vN and vN.M tags.
• Create a release on the market.

The current tasks field has task configs as its first level citizen. This can be weird for global plugins (i.e. plugins that only needs to be configured once per repo). For example, the job_runtime should only be included in one task, but currently it is possible to set it in multiple tasks.

A stoat config schema that can enforce the uniqueness of global plugins is as follows. It adds a plugins field, under which plugin configs are first level citizens:

----
version: 1
enabled: true
plugins:
  static_hosting:
    jest-coverage-report:
      path: /coverage/lcov-report
      metadata:
        name: `jest` report
    jacoco-report
      path: /build/jacoco/report
      metadata:
        name: `jacoco` report
  job_runtime:

However, it is possible that it is not a good idea. A plugin that is "global" today may not be the case tomorrow. For example, there may be legit use cases for setting up job_runtime tasks multiple times so that different jobs can have their runtime chart presented in different styles or formats. So we should not rush in the implementation of this issue.

stoat init failed in stoat-dev/example-elixir#2 even though the workflow file appears to be valid YAML with the warning:

Skipping workflow build.yaml: invalid YAML

• PR: #71
• It's likely because the PR was created from a fork.

The current approach won't work well for large files.

When the Stoat app is not installed, the Stoat comment won't show up in the pull requests, which can be confusing to users.

Here is the solution if the Stoat config is enabled, but the Stoat app is not install:

• Add a warning in the log.
• Mark the Stoat step as skipped.

This issue depends on the tracking of Stoat app installation implemented in https://github.com/stoat-dev/stoat/pull/139.

See #46 (comment) for details and current problem.