Support actions syntax tokens

[silverwind]

TODO:

• Make folding work, default to folded state
• Recalculate rendered line numbers to exclude always-hidden lines
• Figure out whether ::add-matcher and ::remove-matcher have any meaning to us
• Implement all documented tokens
• Error annotations ##[error]
• Add tests

Also there seems to be some strange emoji-prefixed stuff which I think comes from either act_runner or act, I wonder what to do with it because I think these are invalid with that 💬 prefix.

  💬  ::debug::clean = true
  💬  ::debug::filter = undefined
  💬  ::debug::fetch depth = 1
  💬  ::debug::fetch tags = false

[a1012112796]

full commands list is here: https://github.com/actions/toolkit/blob/main/docs/commands.md#problem-matchers

[wolfogre]

Also there seems to be some strange emoji-prefixed stuff which I think comes from either act_runner or act, I wonder what to do with it because I think these are invalid with that 💬 prefix.

I can help remove the emoji prefix if it's really bothering. I noticed that too, but I didn't have the motivation to resolve it.

[silverwind]

Also there seems to be some strange emoji-prefixed stuff which I think comes from either act_runner or act, I wonder what to do with it because I think these are invalid with that 💬 prefix.

I can help remove the emoji prefix if it's really bothering. I noticed that too, but I didn't have the motivation to resolve it.

Please do. I would code this matcher to only work when :: or [command] is at the beginning of the line, and I think such tokens in the middle of the line would also not work on GitHub, but I will check this as well what their renderer does in that case.

[wolfogre]

Also there seems to be some strange emoji-prefixed stuff which I think comes from either act_runner or act, I wonder what to do with it because I think these are invalid with that 💬 prefix.

I can help remove the emoji prefix if it's really bothering. I noticed that too, but I didn't have the motivation to resolve it.

Please do. I would code this matcher to only work when :: or [command] is at the beginning of the line, and I think such tokens in the middle of the line would also not work on GitHub, but I will check this as well what their renderer does in that case.

https://gitea.com/gitea/act/pulls/97

And I'll update act_runner later.

---

https://gitea.com/gitea/act_runner/pulls/515

[techknowlogick]

act_runner has now received the updates

[ChristopherHX]

Figure out whether ::add-matcher and ::remove-matcher have any meaning to us

Those commands needs to be interpreted by act_runner/act.

I would like that ##[group] and ##[endgroup] would work as well

The actions/runner converts them into the alternative (aka azure devops notation) command syntax

https://gitea.com/ChristopherHX/actions_runner/actions/runs/97

##[group]Run actions/checkout@v3
with:
  fetch-depth: 0
  repository: ChristopherHX/actions_runner
  token: ***
  ssh-strict: true
  persist-credentials: true
  clean: true
  sparse-checkout-cone-mode: true
  fetch-tags: false
  lfs: false
  submodules: false
  set-safe-directory: true
##[endgroup]

Both act and actions/runner supports the two different command syntaxes.

Obviously I could tell my third party runner adapter to convert it back, not a big deal after all.

[silverwind]

Figure out whether ::add-matcher and ::remove-matcher have any meaning to us

Those commands needs to be interpreted by act_runner/act.

Ok then we hide those completely on the UI.

[silverwind]

Adding a note for another thing I discovered in the renderer:

Lines that match a certain regex with filename at the start are highlighted as error, but as seen below that regex of GitHub has a bug where it does not highlight column ranges.

No idea how those error annotations look in the raw format, but I expect there to be some token that can be matched.

[ChristopherHX]

The bug with line ranges is probably in this file https://github.com/actions/setup-go/blob/main/matchers.json

1. setup-go prints ::add-matcher:: with a container file path
2. runner reads it from the host by reverse mapping the container path (act could use docker cp like api)
3. runner scans log output for all problem matchers / rewrites the log file and sends annotations for them as well

I'm not shure how it is possible to avoid replicating the line range bug without implementing builtin problem matchers on either UI or runner side.

E.g. the Gitea Workflow could register it's own problem matcher, which matches for line ranges

[silverwind]

Interesting, I wouldn't have thought that it was setup-go that holds this regex. I do agree we should not try to fix this bug on our end, but fix in setup-go instead.

BTW, I think the format <linenum>:<colnum>-<colnum> that gopls uses is not ideal because it would not allow to make a multi-line annotation. A format like <linenum>-<colnum>:<linenum>-<colnum> would arguably be better, but I'm not sure whether the LSP protocol would allows it.