proactionhq / proaction Goto Github PK

If a workflow is found using a branch and the unstable-github-ref is producing a recommendation, it should attempt to find a tag or commit that matches the current ref to minimize the chance of breaking

Currently the outdated check recommends a SHA -> SHA upgrade. But what about "stable" tags? i.e. why doesn't the github.com/actions/checkout@v1 recommend updating to github.com/actions/checkout@v2?

To do this, we can't simply look at commit dates, we need to semantically sort the tags. Because GitHub recommends (and most follow) using semver here, this should be reasonably easy.

Invalid syntax should be reported.
Too often (more frequently than every 5 minutes) should be reported

When proaction is running, the cursor is removed so show the "spinner". When there's an error in the scan and there's a non-zero return code, the cursor is not restored to the terminal

Instead of running all checks sequentially (part of the issue in #23), the CLI could show all of the actions and each check that needs to run, with a spinner on each, indicating what's happening and what's still running...

job: build-proaction
  step: actions/setup-go@v1
    outdated-action:    ✓
    unstable-github-ref: ✓

each step should complete before moving to the next, replacing the content on the screen with the next step.

What's a better name for this check? The check name should be short and clear, meaning the opposite of immutable.

Some ideas:

• inconsistent-github-ref
• altered-github-ref

When there isn't a tty, Proaction should not attempt to redraw the CLI. The current behavior causes a lot of noise when running in a CI system

Currently, it shows a somewhat unhelpful message:

proaction scan
Error: requires at least 1 arg(s), only received 0

Scan command will accept a GitHub URL and download/scan that file. But it errors if given the "Raw" command from.

There are a few TODOs in the code where a tag is checked against a known set of stable/unstable tags. We should finish this so that we don't recommend moving away from stable good tags, but instead only known unstable tags.

They have different description, but both sound like they'd do the same thing:

      --diff            when set, instead of writing the file, just show a diff
      --dry-run         when set, proaction will print the output and recommended changes, but will not make changes to the file

when an action is a owner/repo/path format, the path is currently dropped on the recommendation

Proaction should be a GitHub action that can be executed in a workflow to update other workflows.

The following workflow YAML fails with "unsupported reference":

name: ""
on:
  - pull_request

jobs:
  test:
    steps:
    - name: "test"
    - uses: ./actions/containers

Currently, the implemented checks are all Go code in the pkg/checks directory.
This proposal is a WIP design to reimplement these as policy.

Motivation

• Policy files can be loaded and configured at runtime, allowing for use cases that are not implemented specifically in the code
• When running many policies or many workflow checks, Proaction will likely need to check the same data from the GitHub API multiple times. Policies would eliminate this because they execute offline.
• Policies would be able to cache some inputs, lowering the number of requests made to the GitHub API

Implementation

There are several popular Policy engines available to consider:

• OpenPolicyAgent
• HashiCorp Sentinel

Workflow

The policy approach would be to design a single input, and allow each check to be defined in a runtime loaded policy document.

Input

The input for a workflow must contain all of the data necessary to evaluate the policy. This is simple for some data, but many policies rely on the GitHub API to get the current state of the Action to aid evaluation.

In these, a defined set of data will be statically assumed and provided to the check as input to the policy.

Additionally, each check should define the data to include, and a process will deduplicate the data thats needed before any is collected. This is done to minimize the number of GitHub API requests made and to improve the execution time of the checks when they don’t need all data.

setup-go

goreleaser

Better CLI help command should be written

When an action is using the latest tag that is not listed in the recommendations, proaction remediates to the recommendation.

When an action is using the recommended tag but not the latest, proaction remediates to the latest.

Recommendations should always take priority.

$ proaction version
Proaction 0.1.0

Unable to check for newer releases: find latest release: Get https://oss.proaction.io/version/install?version: dial tcp: lookup oss.proaction.io on 192.168.155.1:53: no such host

This is the endpoint that it can check for the latest version. We can either implement this endpoint or replace this with a call to the GitHub API for the latest version

Cloning the repo and running

make proaction
./bin/proaction scan --diff .github/workflows/build-test-deploy.yaml 

Produces:

 ⠋ Scanning workflow fileError: failed to scan workflow: failed to run unstable outdated-action check: failed to execute outdated action check: failed to get ref type: failed to get commit ref: GET https://api.github.com/repos/actions/setup-go/commits/v1.1.2.1.2: 422 No commit found for SHA: v1.1.2.1.2 []

This makes integration tests break often