Most actions broken as of 0.5.0

Running most actions (see https://github.com/jjkinsey/testing-popl-actions/runs/4536991605, https://github.com/jjkinsey/testing-popl-actions/runs/4536991736 for minimal examples) produces the error:

Error: failed: Error: Error parsing yaml file for unpack-solution: Error: ENOENT: no such file or directory '/home/runner/work/testing-popl-actions/testing-popl-actions/export-solution/action.yml'

This seems to be coming from this line, present in 14 actions:

powerplatform-actions/src/actions/unpack-solution/index.ts

Line 12 in 410aeaf

    
           const parameterMap = taskParser.getHostParameterEntries(runnerParameters.workingDir, "unpack-solution");

The YamlParser class looks for the workflow YAML file but can't find it, as the working directory doesn't include actions when they're used normally from another repository (they're instead located under /home/runner/work/_actions/, at least is what I found in my testing; not sure if that's a stable interface or not).

This bug effects the following actions:

backup-environment
check-solution
create-environment
copy-environment
delete-solution
deploy-package
download-paportal
export-solution
import-solution
pack-solution
unpack-solution
update-solution-version
upgrade-solution
upload-paportal

@jjkinsey please enable lfs in your checkout action of your workflow: our GH Actions have larger binaries that are stored in git LFS in your workflow:

    - uses: actions/checkout@v2
      with:
        lfs: true

https://github.com/jjkinsey/testing-popl-actions/runs/4540547441
https://github.com/jjkinsey/testing-popl-actions/runs/4540547699

Here are some updated runs with LFS enabled in the checkout action of the workflow. I don't think that affects how the repository containing the actions (that is, microsoft/powerplatform-actions) is pulled, though?

is there any update on when the above actions will run correctly when the bug will be fixed?

upgrade-solution is still not working

@jjkinsey @VG-CoE-QA apologies for the delay on this issue. I found the root cause for the issue: we've added code to validate each action's input properties using information of its action.yml. That code unfortunately and wrongly assumed a location that lies within this repo. That assumption breaks obviously, once the powerplatform-actions are referenced from a separate repo:
The GH runner loads the tarball archive of the referenced version/tag into a folder outside of the consuming repo.

Since we have not yet create any automation that consumes our actions from a separate repo, this regression sadly slipped through. Apologies for the pain it created, and thank you for reporting and answering my questions.

Fix candidate is in PR #159 and will be released as 1.51/v0/latest tomorrow Tue (PST), once we've finished additional checks.

A short-term mitigation (beyond using the @0.4.3 tag in your flows), you can use the current PR branch's commit id. But note that this commit id will eventually go away, once the fix is merged to main and the branch gets GC-ed by git.

pin actions in your workflow like this:

      uses: microsoft/powerplatform-actions/who-am-i@8ba95505ed62b2f34974e440ce908f927e24beff

verified manually using the latest main branch commit id in this run:
https://github.com/davidjenni/pp-actions-sample/actions/runs/1608145194

Fix has been released as @0.5.1; the @v0 and @latest tags also point to the same commit id:

https://github.com/microsoft/powerplatform-actions/releases/tag/0.5.1