xt0rted/problem-matcher

Consumer of GH Action appears unable to find dist/ build artifacts?

electronjoe opened this issue · 4 comments

Big thank you for this awesome Template! Super userful and such high quality work. Excellent comments, test coverage.

I'm working on a GCC problem-matcher with support for fromPath annotations. I've taken your Template problem-matcher and made one commit's worth of modifications Here.

My repo appears to be going through post-submit compile and test fine - e.g. see Here.

I have a super simple secondary repo that is intended to prototype this fromPath GCC warning capability. When I submit a PR intended to trigger the findings - I'm getting an error on fetch of electronjoe/gcc-problem-matcher-ts.

Error: File not found: '/home/runner/work/_actions/electronjoe/gcc-problem-matcher-ts/v1/dist/index.js'

Here is an example GH Action failure that uses the above electronjoe/gcc-problem-matcher-ts.

I'll keep exploring! I'm really a typescript greehorn. Some of my questions I'm working to answer msyelf include:

  • I'm finding that when I rpm run build in gcc-problem-matcher-ts
    • what I infer is the final index.js we want is stored to lib/ (not sure why not dist/)
  • The path being attempted by the gcc-problem-matcher-ts load surprises me
    • Why does it expect the action in gcc-problem-matcher-ts/v1/... How is that generated?
  • I looked at build artifacts from the repo e.g. on my v1 tag
    • As I wondered if perhaps there was a TS compile and artifact generation going on?
    • But I do not see anything other than source code being output (no javascript dist/)

Welcome assistance! Hope you are having a great week.

I think I got it!

The missing piece of the puzzle was that once I had my repo all happy and set up - I needed to:

npm run package
npm run release

The release in particular generates the distribution output directory and adds it to a git commit. Seeing if this solves my issue!

Indeed, that addressed my issue!

Alas - it seems my objective is not entirely feasible as-intended.

The multi-line problemMatcher must strictly apply pattern-for-line. This limitation prevents me from using e.g. manual annotations in my logs for the project root directory (fromPath). Looks like a loop operation is supported but not a "match this sequence with arbitrary non-match lines between."

I'm glad you found this helpful. The process to do a new release isn't really documented, but this is generally what I do for each of my actions (it's a powershell script):

# in my profile: function purge { Remove-Item $args[0] -Recurse -ErrorAction Ignore }
purge dist && purge lib && purge node_modules

git checkout releases/v1 && git merge main

purge dist && purge lib && purge node_modules

npm ci

npm run lint --if-present && npm test

npm run build && npm run release

git commit -m "Release v1.1.0"      # creates the release commit
git tag -fa v1 -m "Update v1 tag"   # updates the v1 tag to point to the latest release
git push origin && git push origin v1 --force

I use the website to create the actual release which also creates the v1.1.0 tag but that could be part of the script too.

There's a number of limitations that problem matchers have with file paths. If I'm understanding this correctly your log output contains the file's name, but doesn't contain the file's path. One of the features that's been asked for is a way to supply the path through another field or use the script's working directory but so far there's been no traction on it.

Here's a couple issues that might be useful: