[BUG]: Incorrect physical location for composite actions in subdirectories

[Bo98]

Pre-submission checks

• I am not filing a feature request. These should be filed via the feature request form instead.
• I have looked through the open issues for a duplicate report.

Expected behavior

The physical location contains the full path from the root of the repository.

"logicalLocations": [
  {
    "properties": {
      "symbolic": {
        "key": {
          "Local": {
            "path": "/home/runner/work/repository/repository/subdirectory/action.yml"
          }

[...]

"physicalLocation": {
  "artifactLocation": {
    "uri": "subdirectory/action.yml",
    "uriBaseId": "%SRCROOT%"
  },

Actual behavior

The physical location is always action.yml regardless of how nested it is.

"logicalLocations": [
  {
    "properties": {
      "symbolic": {
        "key": {
          "Local": {
            "path": "/home/runner/work/repository/repository/subdirectory/action.yml"
          }

[...]

"physicalLocation": {
  "artifactLocation": {
    "uri": "action.yml",
    "uriBaseId": "%SRCROOT%"
  },

The result of this is that GitHub code scanning will not show where the problem is.

Reproduction steps

1. Create a composite action that fails an audit.
2. Make sure that action.yml is in a subdirectory, e.g. subaction/action.yml
3. Run zizmor --format sarif.
4. Note the physical location does not contain the subdirectory.

Logs

I can DM you a real-world example where this happened.

Additional context

No response

[woodruffw]

Thanks @Bo98! Yeah, please DM me a real-world example and I'll try and fix this.

[woodruffw]

Ah yeah, I think I know what's happening here -- there's a bit of logic in the SARIF producer to obtain an appropriate "subjective" relative path, but that logic is incorrect in the action (non-workflow case).

(The reason we need this logic at all is because zizmor supports arbitrary paths as inputs, not just repo directories.)

[woodruffw]

#453 should do the trick, although I don't have a great way to test it. If that doesn't work then the next thing will probably be to handle inputs correctly more generally, i.e. actually distinguish repo-like and path-like inputs so that the former can be presented more sanely in the SARIF.