Overview

Currently, @all-contributors bot isn't working at all as shown in here.

It is currently unknown what causes this.

Overview

Technically, the action itself is already usable. However, the code itself is really dirty and centralized in a single file, which made the project:

1. Hard to maintain
2. Hard to debug
3. Hard to extend

Solution

We need to rewrite the entire project using best practices like separation of concerns to multiple files, adding unit tests, adding concise logging, and rewriting the entire documentation.

Overview

Please add a feature that requires all valid pull request to be rebased.

Background

TBD

Proposed Solution

Add a new flag rebase that enforces the pull request branch to be rebased before merging.

Blockers

How do we know that a branch has been rebased or not?

Overview

Please add a feature that enforces all valid pull request branches to be up-to-date.

Background

When merging pull request, oftenly there are conflicts that are caused by a not-up-to-date branch being merged. This unwanted chore can be absolved by simply enforcing the merge branch to be updated before it's being merged.

Proposed Solution

Add a new flag latest that enforces up-to-date branches.

SUMMARY

Given the recommended workflow (in "README.md" or in ".github/workflows/cpr.yml"), Conventional-pr does not re-validate pull requests after each push to the pull request. This can allow unconventional commits to be pushed to the pull request while the until the pull request's status is updated to trigger cpr's workflow and run it against the latest commit of the pull request.

This may require support on GitHub's end to allow workflows to be triggered by "pushes to pull requests" unless there is an existing Action that exposes equivalent functionality or the logic needed to determine if the current commit was pushed to a pull request branch.

DESCRIPTION

Given the following workflow file...

name: Conventional Pull Request
# See https://github.com/Namchee/conventional-pr

on:
  pull_request:
    types: [opened, reopened, ready_for_review]

jobs:
  cpr:
    runs-on: ubuntu-latest
    steps:
      - name: conventional-pr
        uses: Namchee/[email protected]
        with:
          access_token: ${{ secrets.GITHUB_TOKEN }}

...subsequent pushes to a pull request will only be checked when the status of the pull requests is changed to Opened, Reopened, or Ready.
Otherwise, new and possibly unconventional commits will not be validated.

The following is the result of checks triggered by a subsequent push to a pull request. Notice the lack of Conventional Pull Request.

This next image shows that Conventional Pull Requests will re-check a pull request if the status of the pull request is changed to Ready.

SOLUTION(S)

It would be more convenient if the Action could run after every push to the pull request.

1

GitHub probably does not expose a bool or Event for this purpose i.e. "pull_request_push".
So, a third party Action would need to be depended upon–or in-house logic would need to be implemented–to determine if the current workflow run was triggered by a Push event.
If true, then check if the target branch of that push is a pull request branch.

Unfortunately, this proposed implementation would require a workflow run to check for very Push event. This is undesirable, but there might not be an alternative.

2

If GitHub does have an event specifically for subsequent pull request pushes, then this issue will be much easier to resolve.

Overview

Recent pull requests such as #70 #68 fail the workflow check due to an error on golangci-lint. It is advised to consult this error to the maintainers of the action.

Overview

Judging from this issue, it is really hard to debug the actual cause of the error. Therefore, when logging the error, we need to include the actual error message.

Overview

From testing on a private repository after #60, some whitelists' and validators' descriptions are too long and simply redundant.

Some of the examples:

1. Pull request is submitted by a user with high privileges and should be ignored can be rewritten to Pull request is submitted by administrators and should be ignored
2. Remove (s)-es from all validator descriptions.

I'm getting "Pull request does not mention any issue" even though the body of my PR contains the closed issue. It looks like this:

Closes #1234

while 1234 is a valid issue which was selected from GitHubs auto-complete dropdown (when pressing '#').

One thing that might be important is that we are using a different branch than "main" against which we want to merge the PR to. We have main too and main is the default branch. So we are NOT merging against the default branch (in case that might be an issue).

Overview

Due to #67, it has been established that this action doesn't support forked repositories by default as it may lead to GitHub action write access exploit.

Version 0.10.1 enables forked repositories support by default. However, it also removes the default labeling behavior although it is possible to keep the default label behavior by changing the event target from pull_request to pull_request_target by sacrificing some security factors.

For users' convenience, we need to document why and how to enable forked repository support.

We use jira-prepare-commit-msg with Husky and thus automatically add the Jira issue ID to the git commit. The whole thing is checked in advance for conventional commit.

However, the hook then fails, so I made a small adjustment as a pattern regex:

Default:
title_pattern: '([\w\-]+)(\([\w\-]+\))?!?: [\w\s:\-]+'

with Jira issue key (\[([A-Z]+\-\d+)\] )?

Default Regex + Jira Issue Key:
title_pattern: '([\w\-]+)(\([\w\-]+\))?!?: (\[([A-Z]+\-\d+)\] )?[\w\ s:\-]+'

Is there an easier way without regex?

      - name: '✅ Lint PR'
        uses: Namchee/[email protected]
        with:
          ...
          title_pattern: '([\w\-]+)(\([\w\-]+\))?!?: (\[([A-Z]+\-\d+)\] )?[\w\s:\-]+' # with Jira issue key (\[([A-Z]+\-\d+)\] )?
          message: |
            This Pull Request doesn't follow the [conventional commits pattern](https://www.conventionalcommits.org/en/v1.0.0/)

It would be good if this action can also validate all commits made to the pull request.

Hello,

Currently when the check is not passing we have only the message: "Failed to close pull request".

But it could be due to several reason.

Overview

As being discussed here, this action will close any pull requests that have been submitted by a bot with varying rejection reason (most notably, doesn't link to an issue).

This is actually an undesirable behavior, as some bots rely on pull requests to help users to manage their repositories such as dependabot.

This issue may be fixed by specifically ignoring any bot-submitted pull requests.

Currently, the action version is outdated. Kindly bump it.

Overview

To keep pull requests reviewability, the number of file changes per one pull request should be limited.

Smaller pull requests which have only 1-3 file changes are generally easier to be reviewed than one huge pull request which changes 10+ files.

Overview

Currently, any changes in a pull request that needs re-validation are reported in form of a new comment. This might be a good option for small repositories that don't have too many activities. However, this is impractical on big repositories that might change the pull request state often as it might clutter the pull request itself.

Add an option to toggle editing instead of publishing new report.

PR link to an issue is reporting success while no issue is either linked or mentioned

See Th3S4mur41/playground#52 for an example

Overview

The project cannot be renamed to ethos as it has already been used. This will cause the action to not be able to be released to GitHub marketplace.

Solution

Rename it back to conventional-pr

Overview

Please improve the non-verbose output clarity to be at least close to the verbose output.

Background

Since v0.12.0, conventional-pr has a verbose flag to reduce verbosity on the generated report.

However, the quality of the report is not in par to the verbose report. Compared to the verbose report below,

The non-verbose report feels incomplete since it's only constructed from simple output logging.

Proposed Solution

To enhance the clarity, it would be better if the non-verbose report can be presented in table format.

Overview

Currently, ReadEvent does not have a unit test on it due to OS filesystem mocking difficulties.

However, 1.16 brings fresh air to the file reading system by bringing a virtual file system through the io/fs package. This package made it possible for us to easily mock the filesystem.

Solution

Implement a unit test for ReadEvent function by refactoring it to use fs.FS interface.

Overview

Currently, this project uses GitHub REST API v3 to interact with GitHub data such as issues, pull requests, etc. However, the REST API is proven to be insufficient which can be seen in #93.

To address this issue. GitHub itself recommends us to migrate to GraphQL.

Solutuon

Migrate all data fetching logic to GitHub GraphQL API v4. We can use this library to replace the v3 library.

I have tried both template: and template: "" and both are still leaving a comment in the PR. Here's my full action yaml file:

name: Check PR title
on:
  pull_request:

jobs:
  cpr:
    runs-on: ubuntu-latest
    steps:
      - name: Validates the pull request
        uses: Namchee/[email protected]
        with:
          access_token: ${{ secrets.GH_TOKEN}}
          close: false
          title_pattern: <my-custom-regex>
          issue: false
          template: ""
          label:

Overview

Taking a small peek at GitHub actions definition that is stored on action.yml shows that access_token required constraint is badly formatted since it's filled with an empty string. This will potentially cause a buggy behavior that made access_token is not actually required.

Solution

Change the value to true

HaloSPV3/Gemini#101

Why?

snyk-bot is an automated user account instead of a GitHub Bot. It will need to be manually whitelisted until the Snyk organization uses a GitHub Bot.

Hello,

I have an issue with the GITHUB token. I am sure that the code I am using worked before so it's perhaps a github bug or something which is not possible anymore.

Here is the workflow in error:
https://github.com/smutel/go-netbox/runs/6091006484?check_suite_focus=true

Here is my github action configuration:
https://github.com/smutel/go-netbox/blob/a2b97bdc1e2075863750b909428f624c89539f5a/.github/workflows/pr.yml#L13

Here is the answer from someone from the support:
https://github.community/t/403-resource-not-accessible-by-integration/245926

Do you have an idea of how to bypass this in a secure way ?
Do I need to create a personal token ? What is the needed options for that token ?

Overview

Currently, this action will only write error logs in case of something unexpected occurs. This is actually a desirable option in most cases.

However, the current logging behavior complicates the debugging process as shown by #17. To solve this problem, the action should also write a log when the action exits gracefully.

Overview

Currently, the reporting still shows the bot as ethos instead of conventional-pr, which is actually incorrect.

Solution

Rename it back to conventional-pr

DO NOT CLOSE

This is a dummy issue.

Overview

After rewriting the entire project, Go Report Card reports the code with a really low score of C.

The report card actually shows that the code itself mainly have formatting and documentation issues (missing documentations, bad code formatting, etc).

The issues are easily solvable and can be resolved with minimal effort.

See workflow log https://pipelines.actions.githubusercontent.com/vrxKjI15oqtQ0QfJbwIjUvrCt81sTBzO7PTrE7c9avltG3xCYZ/_apis/pipelines/1/runs/2/signedlogcontent/2?urlExpires=2021-11-25T04%3A14%3A44.2205334Z&urlSigningMethod=HMACV1&urlSignature=U0y0M5tPwzHpkoFMIx3yqvzhi0FJHAGyHe%2Fshw01wTM%3D

No diagnostic data available.

Overview

We need to convince users on why some validators are necessary to help them maintain pull requests and get the best out of conventional-pr.

At the same time, we also need to explain why sometimes, whitelisting a pull request is necessary and won't drop pull requests quality.

Overview

We need to add contributors to the documentation to show our appreciation.

Overview

When closing a nonconventional pull request with a commit that doesn't follow conventional commit rules, the comment should refer which commit that doesn't follow the rules. However, it seems that the action cannot refer to the commit in question.

The default config generates a lot of noise even when the PR validation succeeded. I would expect the default behavior to be silent on success and noisy on failure. Optionally, e.g. for debugging, the current verbose report style could be used.

This may also be exacerbated by #76.

As a way to circumvent this, I'm using report: false and template: '...'. That way I only get a comment when the checks fail, but on the other hand no new comment is added when the issues were fixed.

Overview

As introduced by #96, we are dropping signed or verified validator in favor of native GitHub signature verification. Remove the option from action.yml and remove the documentation from the README.

Running the conventional-pr action on an on premise GitHub Enterprise server results in a bad crendentials error.
The error is misleading though and results from the fact that the action is trying to fetch the pull request data from github.com instead of the actual GitHub server.

Run Namchee/[email protected]
2023/09/06 06:23:14 [INFO] Initializing conventional-pr
2023/09/06 06:23:14 [INFO] Reading configuration from environment variables
2023/09/06 06:23:14 [INFO] Reading repository metadata
2023/09/06 06:23:14 [INFO] Initializing GitHub Client
2023/09/06 06:23:14 [INFO] Reading pull request metadata
2023/09/06 06:23:14 [INFO] Validating pull request sub-events
Error: /06 06:23:14 [ERROR] Failed to fetch pull request data: GET https://api.github.com/repos/***/***/pulls/20: 401 Bad credentials []

All references to https://api.github.com should be replaced through ${{github.api_url}} to allow the action to work on Enterprise server

Action version is currently outdated. Kindly bump the version.

Hello,

The conventional-pr is not working anymore on my project.
We can see that in this PR: https://github.com/smutel/terraform-provider-netbox/pull/41/checks, the user did'nt respect de conventional commits. However nothing appends in the MR except the pipeline has failed.

Recently I put the option strict: false but I am not sure that it it the root cause of this issue.
Thanks in advance.

Overview

Currently, all invalid PRs are automatically closed thanks to close option. While this is feasible on personal projects, it doesn't seem to be feasible in bigger projects.

Please change the default value of close to false and write to log when a PR is closed.

Overview

Signed commit is a process of signing a git commit using a trusted GPG key. Signed commits are useful as proof of code ownership and preserve code integrity.

This feature will be added in form of validator function.

When "verbose" is set to true, conventional-pr fails to write the report to the PR. Response is "422 Invalid request". The response from GitHub API says:

No subschema in "oneOf" matched.
"commit_id", "path", "position" weren't supplied.
"in_reply_to" wasn't supplied.
"commit_id", "line", "path" weren't supplied.
"commit_id", "path", "subject_type" weren't supplied. []

Overview

Currently, PR validation result only shows whenever the PR passes a whitelist or validation function without knowing if the whitelist or validation function is even activated or not.

It would be better if the PR validation result for all whitelists and validators are shown with a table, for example:

Overview

Currently, this Docker action took nearly 30 seconds to build the image as evidenced below

Apparently, the build process doesn't utilize Go build caching. Cache the build to speed up the action.

This is a fake issue to test everything.

DO NOT CLOSE!!!

Overview

Currently, the behavior of issue mentions enforces users to manually mention them in the pull request body using special keywords. This behavior creates 2 additional issues:

1. Inflexibility as the number of special keywords is limited.
2. Manual linking via UI doesn't work.

Please implement the link API for this feature instead regex parsing.

It seems that commit message error is not formatted correctly as seen on #7 caused by lack of `` in Sprintf function.

Overview

As shown in the README file, codecov badge shows unknown status.

However, this does not mean that the code is not tested at all as shown in here.

This is probably caused by bad codecov integration.

Hello,

If I understand the code correctly, the message below

But if you check this PR: smutel/terraform-provider-netbox#63

• No message is displayed in the PR check
• This PR is not valid in fact ... because it is not link to an issue