[Bug] Syntax error in 2-find-commit-in-history.yml for needs.find_commit_id

[gitgithan]

There is no job named find_commit_id so needs.find_commit_id, mouseover shows Context access might be invalid: find_commit_id.

How did this step even echo successfully?

[sinsukehlab]

The commit 086ac15 of the PR #26 deleted the step get_find_commit_id.
There had been no job named find_commit_id though.
The check step has checked if the comment body contains null so far.

I would like to open a PR to resolve this issue.

[sinsukehlab]

I have opened the PR #58. Feel free to leave a comment.
Should I rather raise an error than skip the step if the comment body doesn't contain the commit ID?

[cmwilson21]

@gitgithan Thanks for opening the issue and providing the screen shot! ✨

@sinsukehlab Thanks for submitting a PR! I'll get it triaged for review 👍

[gitgithan]

@sinsukehlab
Could you share your process of finding out where that line was deleted?
Based on https://stackoverflow.com/a/68949724/8621823, I tried git log -Gfind_commit_id -p --all to search for all commits where find_commit_id appeared in diff (added or deleted).

Based on output

commit 32160f75139925c746298c3fc64d3e068a5e006b
Author: Kevin Heis <[email protected]>
Date:   Tue Feb 14 11:05:27 2023 -0800

looked closest.

Then I go to https://github.com/skills/connect-the-dots/commits/main/.github/workflows/2-find-commit-in-history.yml, look around Feb 14, to realize that it's a PR, then open PR page (https://github.com/skills/connect-the-dots/pull/26/commits) and click through the 5 commits to see which one mentioned find_commit_id.

This last step isn't feasible if there are too many commits in PR to click through. Gitlens File History git blame doesn't help too since it only shows the commit that added the line (even older commit), not deleted the line.
I'm also unsure how to git blame --reverse on gitlens (to find commits that deleted stuff), and that seems too much effort on CLI since it doesn't even get to the correct commit but is off by 1.

Github network graph didn't help too since it seems the PR branch template-update is already deleted.

Is this how you did it or there's an easier way to find additions/deletions (especially when the changes come from branches that may be merged and deleted already?)

Also how do you test that the changes worked without actually going through the steps 0 -> 1 -> 2 ...

[sinsukehlab]

@gitgithan
I'm not entirely sure that it's an easier way but why don't you browse the GitHub repository page on your browser?
You can view the commit log (git log) and blame a file (git blame) as instructed in this course. The way how I found the changes is as follows. It needs some knowledge on GitHub Actions.
Because the warning occurred on the output (needs.find_commit_id.outputs.find_commit_id), I searched the workflow file of the skills template repository for "$GITHUB_OUTPUT" only to get the other output current_step. While blaming the file, I clicked on the versions octicon on the line that contains "$GITHUB_OUTPUT" (L28) to blame prior to change 3965037 (git blame 3965037^ -- .github/workflows/2-find-commit-in-history.yml) (3965037 only updated the step file path on L28). The commit on L28 then became 32160f7, which is the PR #26 squashed. Finally, I found that the commit 086ac15 of the PR #26 had deleted the step get_find_commit_id of the job get_current_step.
I have tested that the workflows function as expected by actually going through the steps. I opened and merged another PR to push the commit to the main branch of my fork, and then I generated a repository from my fork.