search

actions / runner

The Runner for GitHub Actions :rocket:
https://github.com/features/actions
MIT License
4.82k stars 949 forks source link

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

Open electronjoe opened 3 years ago

electronjoe commented 3 years ago

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.

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 commented 3 years ago

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.

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

This appears possibly overlapping Issue #763 ?

electronjoe commented 3 years ago

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.

screenshot

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

electronjoe commented 3 years ago

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 commented 3 years ago

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

Issues with my environment:

Doing the follow resulted in correct annotation capture:

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
    1. e.g. working directory of /lte/gateway at time of match emission, not /github/workflow/
  3. 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/