Problem matcher annotations are created on the wrong file

[xt0rted]

I'm trying to replace one of my actions with a problem matcher since that fits in to the workflow better, but all of the annotations are being created on the workflow file. The step that's creating them (npm test) is being run with working-directory: src/website which causes the log output to be rooted in the sub folder.

This is the default output from stylelint:

scss/_qr-codes.scss
  9:2   ×  Expected indentation of 2 spaces                        indentation
 11:16  ×  Unexpected unit                                         length-zero-no-unit
 11:28  ×  Unexpected unit                                         length-zero-no-unit
 16:14  ×  Unexpected unit                                         length-zero-no-unit
 19:5   ×  Expected newline after ","                              selector-list-comma-newline-after
 19:5   ×  Expected single space after "," in a single-line list   selector-list-comma-space-after
 20:15  ×  Unexpected unit                                         length-zero-no-unit
 22:14  ×  Unexpected unit                                         length-zero-no-unit
 34:1   ×  Expected indentation of 2 spaces                        indentation
 35:3   ×  Expected indentation of 4 spaces                        indentation
 36:1   ×  Expected indentation of 2 spaces                        indentation
 37:1   ×  Unexpected missing end-of-source newline                no-missing-end-of-source-newline

I saw in #198 that there's a fromPath value that can be used to set the base path of the annotation file. Is there a way to default that to the working-directory value if the file in question couldn't be found?

[ericsciple]

@chrispat fyi. pretty interesting feedback. i like this idea

[chrispat]

We have a work item to fix the problem where annotations with no valid path will not be attributed to the workflow file. I think once that is done you won’t have the problem that you currently see where files that can’t be found are improperly attributed.

[ericsciple]

@chrispat today unrooted paths are rooted against the github.workspace. The feedback is to root against the working-directory input instead

[chrispat]

Ah, I missed that.

That make sense.

[chrispat]

Any concern that we may not know the working directory in the case of many actions? For all JavaScript actions the working directory from the perspective of the runner will be the same as github.workspace, however, in the code the action author could have changed that via process.chdir() and the problem matcher code would not know.

[edhgoose]

@ericsciple, when you say:

today unrooted paths are rooted against the github.workspace

Is that what I'm seeing when I get these notes in the annotations of GitHub Actions:

I've cheated in my problem matcher by adding /github/workspace/ in the regex, but that does not feel like the right way to solve this problem!

{
    "problemMatcher": [
        {
            "owner": "phpcs-csv",
            "pattern": [
                {
                    "regexp": "^\"\\/github\\/workspace\\/(.*)\",(\\d+),(\\d+),(\\w+),\"([^\"]+\",[^,+]*)",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5
                }
            ]
        }
    ]
}

This is currently a private repo for PHP CodeSniffer, which outputs lines like:

File,Line,Column,Type,Message,Source,Severity,Fixable
"/github/workspace/src/our/path/to/file/ReportingHelperRepository.php",129,13,warning,"Line exceeds 120 characters; contains 133 characters",Generic.Files.LineLength.TooLong,5,0
"/github/workspace/src/our/path/to/file/ReportingHelperRepository.php",203,124,warning,"Line exceeds 120 characters; contains 124 characters",Generic.Files.LineLength.TooLong,5,0
"/github/workspace/src/our/path/to/file/ReportingHelperRepository.php",204,1,error,"Multi-line function call not indented correctly; expected 12 spaces but found 16",PEAR.Functions.FunctionCallSignature.Indent,5,1

Is there a better way, or is this issue the right place to track the problem?

[ericsciple]

@edhgoose can you confirm the step is a container action (i.e. uses syntax) and not an ad hoc script (run syntax)? I just skimmed the source code, i think i know what the bug is. Technically actions/runner would be a better place for the issue (recently changed to public repo). I can open an issue there for the issue you described or you can, either way is fine. I'll work on a fix tomorrow.

[edhgoose]

@ericsciple

This is in .github/workflows/phpcs:

on: [pull_request]

jobs:
    phpcs:
        runs-on: ubuntu-latest
        name: Do PHP CS Code Quality Testing
        steps:
            # To use this repository's private action, you must check out the repository
            - name: Checkout
              uses: actions/checkout@v2

            - name: Setup Matcher
              run: echo "::add-matcher::./docker/phpcs/problem-matcher.json"

            - name: PHPCS
              uses: ./docker/phpcs # Uses an action in the docker/phpcs directory

So, yes I think is the answer to your question. Maybe best if you open the issue, as you probably can describe the problem better?

[thboop]

Should be fixed by actions/runner#269