Problem matcher annotations not showing up - but appear matched in logs

[electronjoe]

Describe the bug

Edit: I believe there is a bug at play here for atypical workflows, see my conclusion below. Upshot: If you are using a problem matcher on output from a container, ensure that the working directory you are emitting those logs from within the container is a volume mounted from ${{ github.workspace }} in your GH Action Runner VM.

A gcc-problem-matcher I authored from a Template is working when applied to a simple demonstration project. Working specifically meaning the UI annotates -Wunused-variable in the Files changed UI tab of the Pull Request.

When I apply the same gcc-problem-matcher to my desired project in This PR, no such UI annotation appears (though logs indicate that the matcher did hit on the GCC warnings, more below). The following deltas exist that I'm aware of.

• On Magma, I am running the build inside a docker container GH Action YML for build_oai job
• On Magma, paths of the GCC build failures have incorrect prefix for GH expectation
  • Nominal GCC build gives /magma/lte/...
  • So I have am using xo to trim the /mamga/ leaving just lte/... to match repo
  • This appears to me a correct fixup, but I've tried variants with no success

To Reproduce

Steps to reproduce the behavior:

1. Fork electronjoe/magma
2. Submit a Pull Request of /magma pr-gh-gcc-problems branch onto /magma master branch
3. Review the GCC Warnings & Errors check (takes ~an hour to build and run the first time)
   1. Note the gen_build_container job builds the container in which we will compile (~ignore this job?)
   2. Note the build_oai job is the one which actually builds the artifact and uses gcc-problem-matcher
4. Observe build_oai job logs
   1. Successfully match with log output ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:206:7: warning: unused variable 'totally_useless' [-Wunused-variable]
   2. But annotation does not appear on Pull Request code review

Expected Behavior

In the prototype Pull Request to my forked Magma repo, I expect the -Wunused-variable annotation to correctly display in the UI for the pull request - applied to the file lte/gateway/c/oai/tasks/nas/emm/Attach.c in line with the following log message that makes it appear to have successfully problem matched.

2021-03-12T17:41:09.6010505Z ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:206:7: warning: unused variable 'totally_useless' [-Wunused-variable]

This behavior is working in my simple repo Pull Request sanity check which also uses electronjoe/gcc-problem-matcher.

Runner Version and Platform

Pulled from mis-behaving PR build_oai job.

2021-03-12T17:32:32.2587352Z ##[section]Finishing: Request a runner to run this job
2021-03-12T17:32:38.4125097Z Current runner version: '2.277.1'
2021-03-12T17:32:38.4155332Z ##[group]Operating System
2021-03-12T17:32:38.4156339Z Ubuntu
2021-03-12T17:32:38.4156982Z 20.04.2
2021-03-12T17:32:38.4157389Z LTS

Job Log Output

I'm not sure what all is relevant, but here are some bits I thought might be important. Pulled from mis-behaving PR build_oai job. Note that I only observe the ##[warning]when the problem-matcher is firing in GH Action, so that looks good to me.

2021-03-12T17:34:27.9961714Z ##[group]Run electronjoe/gcc-problem-matcher@v1
2021-03-12T17:34:27.9962270Z with:
2021-03-12T17:34:27.9962619Z   action: add
2021-03-12T17:34:27.9962977Z ##[endgroup]
...
2021-03-12T17:41:09.6010505Z ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:206:7: warning: unused variable 'totally_useless' [-Wunused-variable]
2021-03-12T17:41:09.6026310Z ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:677:34: warning: unused parameter 'emm_cause' [-Wunused-parameter]
2021-03-12T17:41:09.6035622Z ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:678:64: warning: unused parameter 'status' [-Wunused-parameter]
2021-03-12T17:41:09.6038602Z ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:1057:54: warning: unused parameter 'base_proc' [-Wunused-parameter]
2021-03-12T17:41:09.6041389Z ##[warning]lte/gateway/c/oai/tasks/nas/emm/Attach.c:1167:65: warning: unused parameter 'emm_context' [-Wunused-parameter]
...

Runner and Worker's Diagnostic Logs

Perhaps this is an important next step. I had attempted to enable diagnostic logs and it seems I failed (as I see no logs of the shape described in this subsection). I'll attempt to generate another run with diagnostic logs now.

[electronjoe]

I'm not sure if this should be in actions/runner or actions/toolkit. I did go looking for related issues and found the following.

• actions/toolkit - Problem matcher annotations are created on the wrong file
  • Interesting for discussion of root directory assumptions
  • And implications that in-Container env could matter (one of the differences for me)
• Problem matcher rooted file path from container action does not work

From the above a comment by @ericsciple:

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

To my eye, the paths being logged by the pattern-match detection logging look good if one assumes they are based upon the repo_root (e.g. lte/gateway....). I'm not sure if that is a safe assumption. Or why a Docker container would matter if the problem matcher is operating exclusively on log streams.

[electronjoe]

I was able to enable diagnostic logs and this is good (that is, looks informative!):

##[debug]Dropping file value '/home/runner/work/magma/magma/lte/gateway/c/oai/tasks/nas/emm/Attach.c'. Path does not exist
Warning: lte/gateway/c/oai/tasks/nas/emm/Attach.c:677:34: warning: unused parameter 'emm_cause' [-Wunused-parameter]
##[debug]Dropping file value '/home/runner/work/magma/magma/lte/gateway/c/oai/tasks/nas/emm/Attach.c'. Path does not exist
Warning: lte/gateway/c/oai/tasks/nas/emm/Attach.c:678:64: warning: unused parameter 'status' [-Wunused-parameter]
##[debug]Dropping file value '/home/runner/work/magma/magma/lte/gateway/c/oai/tasks/nas/emm/Attach.c'. Path does not exist
Warning: lte/gateway/c/oai/tasks/nas/emm/Attach.c:1057:54: warning: unused parameter 'base_proc' [-Wunused-parameter]
##[debug]Dropping file value '/home/runner/work/magma/magma/lte/gateway/c/oai/tasks/nas/emm/Attach.c'. Path does not exist
Warning: lte/gateway/c/oai/tasks/nas/emm/Attach.c:1167:65: warning: unused parameter 'emm_context' [-Wunused-parameter]

[electronjoe]

To my eye, reviewing the above - this looks like a bug someplace in GH Actions? The inferred path for reasons unclear has duplicated the repository name (.../magma/magma/...).

What I might try is giving an absolute path in the log warning, to see what happens then (e.g. postprocess my warnings to give file paths not in lte/gateway... but instead /home/runner/work/magma/lte/gateway/...). Perhaps differing GH Action logic applies.

[electronjoe]

This appears possibly overlapping Issue #763 ?

[electronjoe]

A Github Community post seems to possibly explain this issue. I'll explore this.

As you are using a docker container action ( tchajed/docker-coq-action@no-opam ), the Docker container filesystem is not the same as the runner. The RUNNER_WORKSPACE is mapping to GITHUB_WORKSPACE inside the action container.

You need to use GITHUB_WORKSPACE inside docker container instead of RUNNER_WORKSPACE .

[electronjoe]

From my diagnostics logs, note that the docker-run-action@v2 defaults to dropping you into the --workdir /github/workspace. Based on the above, I wonder if this results in broken path extrapolation by GH Actions? I'm going to try dropping into --workdir /github/workflow and building instead.

2021-03-12T20:17:54.0568163Z ##[group]Run addnab/docker-run-action@v2
2021-03-12T20:17:54.0568663Z with:
2021-03-12T20:17:54.0569069Z image: magma/mme_builder:latest
2021-03-12T20:17:54.0571256Z run: cd /magma/lte/gateway;make build_oai 2>&1 > /compile.log;for file in .github/workflows/gcc-problems.yml lte/gateway/c/connection_tracker/CMakeLists.txt lte/gateway/c/oai/CMakeLists.txt lte/gateway/c/oai/tasks/nas/emm/Attach.c lte/gateway/c/session_manager/CMakeLists.txt lte/gateway/docker/mme/Dockerfile.ubuntu20.04; do grep $file /compile.log | xo '//magma/((.):(\d+):(\d+):\s+(?:fatal\s)?(warning|error):\s+(.))//home/runner/work/magma/$1/' || true; done;
2021-03-12T20:17:54.0573235Z shell: sh
2021-03-12T20:17:54.0573595Z ##[endgroup]
2021-03-12T20:17:54.0616520Z ##[command]/usr/bin/docker run --name e4ad8d511513bd46408c3a80fb3af13977_7ecc79 --label 5588e4 --workdir /github/workspace --rm -e INPUT_IMAGE -e INPUT_RUN -e INPUT_OPTIONS -e INPUT_SHELL -e INPUT_REGISTRY -e INPUT_USERNAME -e INPUT_PASSWORD -e INPUT_DOCKER_NETWORK -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_DEBUG -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/magma/magma":"/github/workspace" 5588e4:ad8d511513bd46408c3a80fb3af13977

[electronjoe]

I have achieved success - but I do believe there is unexpected behavior here.

Issues with my environment:

• Within the container building with GCC and capturing gcc-problem-matcher outputs
  • I was building within a directory tree directly under /, not /github/workflow/
  • This worked because my docker container had a repo checkout at / (a mistake)
  • Due to an issue with docker-run-action /github/workflow/ did not exist

Doing the follow resulted in correct annotation capture:

• Add repo check-out to the Workflow step (it was omitted)
  • This gave me a repo copy in the {{ github.workflow }} directory
• Apply options: -v ${{ github.workspace }}:/work -e ABC=123 to docker-run-actionsv2 action
  • This is strange, hence my GH Issue

To Github actions | runner team, I believe following needs to be addressed more clearly (repaired or documented):

1. When Problem Matcher matches occur in a container and provide a repo-relative path
   1. e.g. a log message that pattern matches a path of lte/gateway/.../file.c:124
2. If that log message is emitted from a directory not within the GitHub workflow volume
3. e.g. working directory of /lte/gateway at time of match emission, not /github/workflow/
4. Github Action converts the non-rooted path to an incorrect complete path
   1. it incorrectly pre-pends e.g. here /home/runner/work/magma/magma/