Automatic SystemVerilog linting in github actions with the help of Verible

Overview

Verible Lint Action

Usage

See action.yml

This is a GitHub Action used to lint Verilog and SystemVerilog source files and comment erroneous lines of code in Pull Requests automatically. The GitHub Token input is used to provide reviewdog access to the PR. If you don't wish to use the automatic PR review, you can omit the github_token input. If you'd like to use a reporter of reviewdog other than github-pr-review, you can pass its name in the input reviewdog_reporter.

Here's a basic example to lint all *.v and *.sv files:

name: Verible linter example
on:
  pull_request:
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - uses: chipsalliance/verible-linter-action@main
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}

You can provide optional arguments to specify paths, exclude paths, a config file and extra arguments for verible-verilog-lint.

- uses: chipsalliance/verible-linter-action@main
  with:
    config_file: 'config.rules'
    paths: |
      ./rtl
      ./shared
    exclude_paths: |
      ./rtl/some_file
    extra_args: "--check_syntax=true"
    github_token: ${{ secrets.GITHUB_TOKEN }}

Automatic review on PRs from external repositories

In GitHub Actions, workflows triggered by external repositories may only have read access to the main repository. In order to have automatic reviews on external PRs, you need to create two workflows. One will be triggered on pull_request and upload the data needed by reviewdog as an artifact. The artifact shall store the file pointed by $GITHUB_EVENT_PATH as event.json. The other workflow will download the artifact and use the Verible action.

For example:

name: upload-event-file
on:
  pull_request:

...
      - run: cp "$GITHUB_EVENT_PATH" ./event.json
      - name: Upload event file as artifact
        uses: actions/upload-artifact@v2
        with:
          name: event.json
          path: event.json
{ return artifact.name == "event.json" })[0]; var download = await github.actions.downloadArtifact({ owner: context.repo.owner, repo: context.repo.repo, artifact_id: matchArtifact.id, archive_format: 'zip', }); var fs = require('fs'); fs.writeFileSync('${{github.workspace}}/event.json.zip', Buffer.from(download.data)); - run: | unzip event.json.zip - name: Run Verible action with Reviewdog uses: chipsalliance/verible-linter-action@main with: github_token: ${{ secrets.GITHUB_TOKEN }} ">
name: review-triggered
on:
  workflow_run:
    workflows: ["upload-event-file"]
    types:
      - completed

jobs:
  review_triggered:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: 'Download artifact'
        id: get-artifacts
        uses: actions/[email protected]
        with:
          script: |
            var artifacts = await github.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: ${{github.event.workflow_run.id }},
            });
            var matchArtifact = artifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "event.json"
            })[0];
            var download = await github.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            var fs = require('fs');
            fs.writeFileSync('${{github.workspace}}/event.json.zip', Buffer.from(download.data));
      - run: |
          unzip event.json.zip
      - name: Run Verible action with Reviewdog
        uses: chipsalliance/verible-linter-action@main
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
Comments
  • Convert to Container Action

    Convert to Container Action

    Close #3

    Unfortunately, when the image is built automatically as part of a Container Action, it seems that global environment variables are not inherited. Therefore, enabling BuildKit globally through DOCKER_BUILDKIT does not work. That would be desirable in order to use https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/syntax.md#build-mounts-run---mount in the dockerfile. For now, I worked around it by using a COPY statement (a layer) instead. Nonetheless, I kept the commit isolated, because it might be reverted when building the image is decoupled from the execution.

    I added a very simple CI workflow for testing the execution of the Action. Yet, since there is no "demo" project here, execution is rather useless. It would be interesting if someone familiar with Verible would contribute an example project in a follow-up PR.

    NOTE: Since GitHub Actions is not enabled in this repository yet, results are not shown below. See https://github.com/umarcor/verible-linter-action/actions

    opened by umarcor 4
  • Always use latest verible

    Always use latest verible

    Similar to the verible-formatter-action, fetch the most recent version of verible and perform the linting.

    Should the same arguments be used as before or should it be done the same way as the formatting action?

    • -f fail fast without html error document
    • -S shows an error message on fail
    • -L follows a redirect
    opened by mole99 3
  • Optimise execution by using a Container Action

    Optimise execution by using a Container Action

    The current implementation of this Action is of type Composite. In the first five steps, the dependencies are downloaded and installed: https://github.com/chipsalliance/verible-linter-action/blob/main/action.yml#L31-L51. In the last step, which is a single bash script, the actual functionality is implemented: https://github.com/chipsalliance/verible-linter-action/blob/main/action.yml#L52-L87.

    I recommend to convert this Action into a Container Action, since having it be a Composite does not provide any meaningful advantage in this use case.

    The advantage of spliting dependency installation into a Dockerfile is that it can be later decoupled. That means, building and deploying the container image on one side, and using it in the action on the other side. As a result, the Action will be executed faster.

    For reference, that approach is used in mithro/actions-includes:

    • https://github.com/mithro/actions-includes/blob/main/action.yml#L27-L29
    • https://github.com/mithro/actions-includes/blob/main/docker/Dockerfile
    • https://github.com/mithro/actions-includes/blob/main/.github/workflows/publish-docker-image.yml

    Similar strategy, without decoupling, in dbhi/qus:

    • https://github.com/dbhi/qus/blob/main/action/action.yml
    • https://github.com/dbhi/qus/blob/main/action/Dockerfile

    and eine/tip:

    • https://github.com/eine/tip/blob/master/action.yml
    • https://github.com/eine/tip/blob/master/Dockerfile
    opened by umarcor 2
  • Push container image to GHCR and use it in the Action

    Push container image to GHCR and use it in the Action

    This is a folloy-up of #4.

    As commented in #3, building the container image separatedly and the using it at runtime can reduce the execution time for users of this Action. In this PR, a workflow is added, which builds image ghcr.io/chipsalliance/verible-linter-action and pushes it to the GitHub Container Registry, using the default token. Then, in the Action, that image is used instead of the Dockerfile.

    • Current execution time (92s): https://github.com/chipsalliance/verible-linter-action/actions/runs/1192256099
    • Image build and push time (131s): https://github.com/umarcor/verible-linter-action/actions/runs/1194493666
    • Execution time using the image (22s): https://github.com/umarcor/verible-linter-action/actions/runs/1194493667

    The workflows are scheduled weekly. Feel free to adjust that to your needs.

    NOTE: CI will fail below because this PR does not have permission for pushing to ghcr.io/chipsalliance. That will work after this is merged to main. Precisely, workflow Container will work as soon as it is merged, and Test will need to be rerun afte the image is pushed for the first time. The references to my fork above did work because I temporarily used ghcr.io/umarcor instead.

    opened by umarcor 1
  • Always use latest verible

    Always use latest verible

    Re-opening of #19 due to an error on my end.

    Similar to the verible-formatter-action, fetch the most recent version of verible and perform the linting.

    opened by mole99 0
  • Colon is missing from error messages produced by reviewdog

    Colon is missing from error messages produced by reviewdog

    Reviewdog reports (e.g. here)

    Unpacked dimension range must be declared in big-endian ([0N-1]) order. Declare zero-based big-endian unpacked dimensions sized as [N]. [Style unpacked-ordering] [unpacked-dimensions-range-ordering]

    Look at the "[0N-1]" string, which should be "[0:N-1]" (the Verible source code agrees with me).

    We somewhere loose the colon in the path between Verible and the GH action reporting.

    opened by imphil 0
  • add GitHub token to test

    add GitHub token to test

    The test would fail because the default reporter is "github-pr-review" and there wasn't a token provided. The reason I change the test, and not the code of the action, is because I assume that the correct usage of the action is to either:

    1. Use a reporter that requires the token ("github-pr-review") AND provide the token.
    2. Use a reporter that doesn't require the token (for example "local").

    The workflow was successful here: https://github.com/antmicro/verible-linter-action/actions/runs/1266083502

    opened by wsipak 0
  • Add action input fail_on_error

    Add action input fail_on_error

    This allows to choose whether the action should fail or not, depending on the result of running Verible. Use fail_on_error: 'true' to fail the action if a rule violation that is relevant to a PR exists.

    For testing purposes, this PRs have been created:

    1. Failing disabled, errors were posted as code review, but the workflow was successful anyway: https://github.com/antmicro/gha-playground/pull/95
    2. Failing enabled, errors were posted as code review and the workflow failed: https://github.com/antmicro/gha-playground/pull/96
    3. Failing enabled, but no rule violations were found, thus the workflow succeeded: https://github.com/antmicro/gha-playground/pull/97
    opened by wsipak 0
  • exit the action without error

    exit the action without error

    Previously, the action would exit with non-zero code whenever rule violations were found, even if the violations did not belong to the changes in PR. We could either change it to return non-zero when violations are relevant, or always return zero. I'm changing this to always exit successfully and my reasoning here is that, if there are relevant violations, we'll see them in code review (so we don't really need the negative flag), and we can use non-zero exit codes for internal errors in the action, not related to output from Verible.

    opened by wsipak 0
  • Fix missing output from action.py

    Fix missing output from action.py

    The newer version of Verible:

    1. Prints rule violations to stderr, not stdout (This caused problems in Ibex repository).
    2. Uses different values for autofix argument (I thought I had added this change already, and I'm adding it now).

    A test PR was recreated here: https://github.com/antmicro/gha-playground/pull/93

    opened by wsipak 0
  • Fix remote url handling when a PR from a fork is created

    Fix remote url handling when a PR from a fork is created

    The action needs to handle two remotes. One for the main repo, and the other for the source of the PR. This wasn't handled properly and is fixed here. The problem appeared here: https://github.com/lowRISC/ibex/pull/1434

    Right now the script retrieves the URL of the remote from event.json and fetches the right branch from it. Additionally, hash of the HEAD is printed so that it's easy to confirm correctness of operation.

    I've checked these scenarios:

    1. The branch used in a PR doesn't exist in the main repo, and it works.
    2. The branch used in a PR does exist in the main repo, and it's actually fetched from the fork. (Previously the script tried to fetch it from mainline)
    opened by wsipak 0
  • List of repos where the action could be used

    List of repos where the action could be used

    We need to compile a list of repositories that contain SystemVerilog or Verilog (even simple test cases) where we could enable the Verible actions.

    Let me start with

    Please comment with suggestions of other repositories CC @hzeller @mkurc-ant @kgugala

    opened by tgorochowik 0
Releases(v1.4)
Owner
CHIPS Alliance
Common Hardware for Interfaces, Processors and Systems
CHIPS Alliance
Python linting made easy. Also a casual yet honorific way to address individuals who have entered an organization prior to you.

pysen What is pysen? pysen aims to provide a unified platform to configure and run day-to-day development tools. We envision the following scenarios i

Preferred Networks, Inc. 452 Jan 5, 2023
Use GitHub Actions to create a serverless service.

ActionServerless - Use GitHub Actions to create a serverless service ActionServerless is an action to do some computing and then generate a string/JSO

null 107 Oct 28, 2022
可基于【腾讯云函数】/【GitHub Actions】/【Docker】的每日签到脚本(支持多账号使用)签到列表: |爱奇艺|全民K歌|腾讯视频|有道云笔记|网易云音乐|一加手机社区官方论坛|百度贴吧|Bilibili|V2EX|咔叽网单|什么值得买|AcFun|天翼云盘|WPS|吾爱破解|芒果TV|联通营业厅|Fa米家|小米运动|百度搜索资源平台|每日天气预报|每日一句|哔咔漫画|和彩云|智友邦|微博|CSDN|王者营地|

每日签到集合 基于【腾讯云函数】/【GitHub Actions】/【Docker】的每日签到脚本 支持多账号使用 特别声明: 本仓库发布的脚本及其中涉及的任何解锁和解密分析脚本,仅用于测试和学习研究,禁止用于商业用途,不能保证其合法性,准确性,完整性和有效性,请根据情况自行判断。

null 87 Nov 12, 2022
Automate HoYoLAB Genshin Daily Check-In Using Github Actions

Genshin Daily Check-In ?? Automate HoYoLAB Daily Check-In Using Github Actions KOR, ENG Instructions Fork the repository Go to Settings -> Secrets Cli

Leo Kim 41 Jun 24, 2022
Mini Tool to lovers of debe from eksisozluk (one of the most famous website -reffered as collaborative dictionary like reddit- in Turkey) for pushing debe (Most Liked Entries of Yesterday) to kindle every day via Github Actions.

debe to kindle Mini Tool to lovers of debe from eksisozluk (one of the most famous website -refered as collaborative dictionary like reddit- in Turkey

null 11 Oct 11, 2022
POC de uma AWS lambda que executa a consulta de preços de criptomoedas, e é implantada na AWS usando Github actions.

Cryptocurrency Prices Overview Instalação Repositório Configuração CI/CD Roadmap Testes Overview A ideia deste projeto é aplicar o conteúdo estudado s

Gustavo Santos 3 Aug 31, 2022
Implement SAST + DAST through Github actions

Implement SAST + DAST through Github actions The repository is supposed to implement SAST+DAST checks using github actions against a vulnerable python

Syed Umar Arfeen 3 Nov 9, 2022
GitHub Actions Poll Mode AutoScaler (GAPMAS)

GitHub Actions Poll Mode AutoScaler, or GAPMAS, is a simple tool that helps you run ephemeral GitHub Actions self-hosted runners on your own infrastructure.

Frode Nordahl 4 Nov 4, 2022
Centralized whale instance using github actions, sourcing metadata from bigquery-public-data.

Whale Demo Instance: Bigquery Public Data This is a fully-functioning demo instance of the whale data catalog, actively scraping data from Bigquery's

Hyperquery 17 Dec 14, 2022
A GitHub Actions repo for tracking the dummies sending free money to Alex Jones + co.

A GitHub Actions repo for tracking the dummies sending free money to Alex Jones + co.

Egarok 2 Jul 20, 2022
Automation that uses Github Actions, Google Drive API, YouTube Data API and youtube-dl together to feed BackJam app with new music

Automation that uses Github Actions, Google Drive API, YouTube Data API and youtube-dl together to feed BackJam app with new music

Antônio Oliveira 1 Nov 21, 2021
42-event-notifier - 42 Event notifier using 42API and Github Actions

42 Event Notifier 42서울 Agenda에 새로운 이벤트가 등록되면 알려드립니다! 현재는 Github Issue로 등록되므로 상단

null 6 May 16, 2022
GitHub Actions Docker training

GitHub-Actions-Docker-training Training exercise repository for GitHub Actions using a docker base. This repository should be cloned and used for trai

GitHub School 1 Jan 21, 2022
A discord.py bot template with easy deployment through Github Actions

discord.py bot template A discord.py bot template with easy deployment through Github Actions. You can use this template to just run a Python instance

Thomas Van Iseghem 1 Feb 9, 2022
GitHub Activity Generator - A script that helps you instantly generate a beautiful GitHub Contributions Graph for the last year.

GitHub Activity Generator A script that helps you instantly generate a beautiful GitHub Contributions Graph for the last year. Before ?? ?? ?? After ?

null 1 Dec 30, 2021
🤖 Automated follow/unfollow bot for GitHub. Uses GitHub API. Written in python.

GitHub Follow Bot Table of Contents Disclaimer How to Use Install requirements Authenticate Get a GitHub Personal Access Token Add your GitHub usernam

João Correia 37 Dec 27, 2022
Github-Checker - Simple Tool To Check If Github User Available Or Not

Github Checker Simple Tool To Check If Github User Available Or Not Socials: Lan

ميخائيل 7 Jan 30, 2022
HTTP Calls to Amazon Web Services Rest API for IoT Core Shadow Actions 💻🌐💡

aws-iot-shadow-rest-api HTTP Calls to Amazon Web Services Rest API for IoT Core Shadow Actions ?? ?? ?? This simple script implements the following aw

AIIIXIII 3 Jun 6, 2022
Tubee is a web application, which runs actions when your subscribed channel upload new videos

Tubee is a web application, which runs actions when your subscribed channel upload new videos, think of it as a better IFTTT but built specifically for YouTube with many enhancements.

Tomy Hsieh 11 Jan 1, 2023