Add a clang-format format check in github pull request actions.

[hzeller]

Issues #653

Signed-off-by: Henner Zeller h.zeller@acm.org

[mithro]

@hzeller -- You might want to add a commit which deliberately break formatting to test it does the right thing?

[hzeller]

I did that in my local test repository: https://github.com/hzeller/verible/runs/1817888890

[umarcor]

Unless you want to have a separate status report and shield/badge for showing the status of this specific test/job independently from others, I would suggest not to create this new workflow. Instead, just copy this job (L7-L19) into the existing workflow.

[hzeller]

Done. I mostly started the new file while experimenting with the new flow, but merging it now makes it simpler.

[umarcor]

Unless this is used somewhere else, I would not recommend adding it as a separate file. Just put it in the workflow. In the current state, this script is platform specific, so not really very useful outside of that specific CI job. If/when it is modified for supporting installation on different environments, then it'll make sense to have it be a file.

[hzeller]

Sounds good. Done.

[tgorochowik]

LGTM in general

[tgorochowik]

2021 😉

[hzeller]

Done.

[tgorochowik]

We could probably use something like:
$(git ls-tree HEAD -r --name-only | grep --color=never -e '\.cc$\|\.h$')

But assuming that this is run before building and before anything is generated I think find should be okay too

[fangism]

There's a recipe for modified files here (git_touched_files):

https://cs.opensource.google/verible/verible/+/master:verilog/tools/formatter/verible-verilog-format-changed-lines-interactive.sh;drc=74b906bcefefbda3dea36abba4a6a2ce5707d5f0;l=127

[hzeller]

Both these assume that the files are local changed. Though I assume within the pull request environment it will already have applied the patch already as we have a clean head without diffs.
So maybe I need something like

git diff --name-only --diff-filter=AM HEAD~1

? Will have to try.

[hzeller]

So I did some experiments in a testing branch, trying to see how the git repository looks like when we're called in an action in a pull request

It looks weird: it looks like a git repository with a single branch (named like the branch from which is pushed) ,but no master branch. There is also only a single commit on it. So it looks like it clones everything, applies all the previous patches in the pull request, uses that as 'git init' baseline in a fresh repository with a single branch and then applies a single patch, which is the last push in that pull request.

Anyway, so this means, not even a git diff --name-only --diff-filter=AM -r origin/master will work.
Apparently, there are github actions scripts on the marketplace that can find all changed files; will have to look into that.

So I suggest for now, we leave it with the find all the files and apply clang-format to them. Which is fine, as we expect the code-base to be clean all the time so that we can afford running the format over all the files, even the ones not touched in the pull request.

[mithro]

You can change how the git repository is cloned.

[mithro]

You can change how the git repository is cloned.

https://github.com/actions/checkout

    # Number of commits to fetch. 0 indicates all history for all branches and tags.
    # Default: 1
    fetch-depth: ''

    # Whether to checkout submodules: `true` to checkout submodules or `recursive` to
    # recursively checkout submodules.
    #
    # When the `ssh-key` input is not provided, SSH URLs beginning with
    # `git@github.com:` are converted to HTTPS.
    #
    # Default: false
    submodules: ''

[mithro]

Also see https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

[hzeller]

Aha, bingo, this seems to be the ticket. Here the output of a run in my test repository: https://github.com/hzeller/verible/runs/1825048661
Thanks @mithro

[hzeller]

Not sure why it didn't run the actions now after the last commit, but it should work now :)
In my test-repo, I did a run that only affected one file, and the github action picked only that up.

[umarcor]

FTR, the actions/checkout is both clever and annoying. Precisely, depth: 0 was added in May, after I reported problems because of the weird checkout procedure: actions/checkout#250. However, it's nice cause it allow reusing the config easily: actions/checkout#300.

[umarcor]

Not sure why it didn't run the actions now after the last commit, but it should work now :)
In my test-repo, I did a run that only affected one file, and the github action picked only that up.

@hzeller, when merging both workflows, the indentation was not the same. At the same time, a | symbol was missing. That's why CI was not running. See #664.

[hzeller]

Ah, interesting, thanks for hunting down the syntax issues.
Where does github show if actions are not running due to syntax issues ?

[umarcor]

You go to the Actions tab above. You see, e.g.:

Fix env-MODE: got unindented in last commit (#665) Signed-off-by: Henner Zeller h.zeller@acm.org
verible-ci #272: Commit 898d507 pushed by hzeller

That's correct, because "verible-ci" is shown in the second line.

When the workflow is defective, you see .github/workflows/verible-ci.yml in there. That is, the path to the file, instead of the name of the workflow. The same happens with the items in the sidebar.

Unfortunately, all that is dynamically generated. Therefore, as soon as we fixed it, those failing items are not shown anymore. That's why I cannot point you to an specific example ATM.

Anyway, the error just points to a line in the workflow. In this case, it was not intuitive to know that the problem was indentation. I knew it because I had hit that problem before.