Various CI pipeline improvements

[pulsastrix]

This PR makes some larger improvements to the libcoap-rs CI pipeline:

• Switched from cargo tarpaulin to rustc's builtin -C instrument-coverage flag+grcov for coverage.
• grcov generates a report in both Markdown and HTML format, with the Markdown being used for the PR sticky comment and the HTML version (that allows looking at the source code directly) being deployed to GitHub Pages and linked in the sticky comment.
• added a job for rustfmt
• switched from giraffate/clippy-action to qnighy/clippy-reviewdog-filter as the former one seems to not always work properly.
• Tests are now run for the Minimum Supported Rust Version, the current stable version and the current nightly release.

[github-actions]

Workflow Status Report

Generated for commit 7e8f879 on Wed Dec 18 23:16:26 UTC 2024.

In case of failure, clippy warnings and rustfmt changes (if any) will be indicated as CI check warnings in the file comparison view.

Documentation: Read Online Download

Coverage Report: Read Online Download

Note: Online versions of documentation and coverage reports may not be available indefinitely, especially after the pull request was merged.

Code Coverage Report

Coverage target is 80%.

Click on the coverage badge to access the full coverage report including a source code view.

Expand to view coverage statistics

file	coverage	covered	missed_lines
libcoap-sys/src/lib.rs	85.94%	269 / 313	141-152, 193, 198, 208, 213, 258, 263, 320-337, 458-461, 541-544
libcoap/src/context.rs	61.50%	230 / 374	93, 151-196, 203-210, 227, 256, 303-306, 340, 355-357, 422, 427, 443, 451-613
libcoap/src/crypto/pki_rpk/key.rs	56.67%	51 / 90	171-210, 234-242, 244-247, 253-255
libcoap/src/crypto/pki_rpk/mod.rs	21.95%	99 / 451	35-278, 449-481, 502-600, 608, 611, 645-663, 673-675, 680-682, 687-689, 750, 762-898
libcoap/src/crypto/pki_rpk/pki.rs	78.08%	114 / 146	77-136, 289-302
libcoap/src/crypto/pki_rpk/rpk.rs	72.60%	53 / 73	61-91, 153-164
libcoap/src/crypto/psk/client.rs	45.07%	64 / 142	70-74, 82, 103-189, 231-239, 266-268, 273-275, 303-335
libcoap/src/crypto/psk/key.rs	61.46%	59 / 96	42-49, 163-205
libcoap/src/crypto/psk/mod.rs	0.00%	0 / 45	28-98
libcoap/src/crypto/psk/server.rs	30.95%	52 / 168	67-86, 94, 97, 112-115, 141-143, 148-150, 155-157, 185-230, 251, 267-392
libcoap/src/error.rs	0.00%	0 / 6	91-171
libcoap/src/event.rs	29.73%	11 / 37	33-166
libcoap/src/lib.rs	0.00%	0 / 64	99-202
libcoap/src/mem.rs	72.89%	121 / 166	145-160, 193-195, 207-209, 277, 293-295, 316-321, 350-352, 366, 378-390, 451-453, 470, 478-485, 504, 524, 528
libcoap/src/message/mod.rs	58.46%	190 / 325	107-110, 112-133, 141-147, 149-170, 174, 176, 178, 210, 212, 215-224, 227-245, 247-251, 267-277, 297-304, 400, 443, 449, 480, 490-493, 499-501, 508, 513-525, 531, 551-553, 563-565
libcoap/src/message/request.rs	34.12%	101 / 296	52, 69-203, 229-257, 265-366, 372-376, 381-382, 384-387, 390, 396-402, 431-433, 437, 440-442, 445-447, 450, 453, 456, 459, 462, 473-480
libcoap/src/message/response.rs	22.17%	45 / 203	33-157, 162, 165, 168, 171, 174, 192-322, 326-331, 357
libcoap/src/prng.rs	55.41%	41 / 74	67, 79-117, 140-150, 197
libcoap/src/protocol.rs	32.58%	58 / 178	145-147, 152-157, 159-174, 176-177, 184-189, 191-206, 208-209, 229-268, 289, 303-305, 347-352, 361-366, 372-383, 437-464, 470-483, 515, 517
libcoap/src/resource.rs	70.49%	172 / 244	64, 96-98, 173-178, 185-210, 216-221, 251, 268-290, 302-305, 330-333, 366-375, 508-510
libcoap/src/session/client.rs	90.00%	135 / 150	156, 183, 212, 220-222, 228-230, 276-282
libcoap/src/session/mod.rs	39.19%	107 / 273	56-65, 96, 106-221, 231-276, 285-288, 297-308, 337, 341, 373-393, 415, 423, 451, 458, 476-482, 558, 564
libcoap/src/session/server.rs	81.33%	61 / 75	69-71, 75, 143, 153-155, 170, 185-191
libcoap/src/transport.rs	70.97%	22 / 31	28-35, 54
libcoap/src/types.rs	58.49%	341 / 583	76-122, 128-157, 200-213, 231-233, 243-255, 262-268, 274-276, 285, 552, 561, 573, 636, 662-731, 784, 829-850, 871-873, 889-894, 905-990
libcoap/tests/common/dtls.rs	100.00%	39 / 39
libcoap/tests/common/mod.rs	98.75%	79 / 80	104
libcoap/tests/dtls_pki_client_server_test.rs	100.00%	82 / 82
libcoap/tests/dtls_psk_client_server_test.rs	100.00%	26 / 26
libcoap/tests/dtls_rpk_client_server_test.rs	100.00%	7 / 7
libcoap/tests/tcp_client_server_test.rs	100.00%	22 / 22
libcoap/tests/udp_client_server_test.rs	100.00%	22 / 22

Total coverage: 54.76%

[pulsastrix]

Quick question to the other maintainers @JKRhb @falko17: Do you think it's worth the effort to also build the documentation and push it to GitHub Pages?

If so, would it make sense to do this for every pull request or only for the main branch?

Doing so for every PR might make it easier for people to review documentation changes, but would also cause many different versions of the documentation to be available at the same time.

As of now, I have not implemented a cleanup mechanism to remove old coverage reports (and possible documentation builds) of merged PRs from the GitHub pages deployment. This could be seen as an advantage (you can see the coverage reports even after the PR was merged), but I'm not sure if this could also have negative implications regarding repository size.

[JKRhb]

Quick question to the other maintainers @JKRhb @falko17: Do you think it's worth the effort to also build the documentation and push it to GitHub Pages?

If so, would it make sense to do this for every pull request or only for the main branch?

Doing so for every PR might make it easier for people to review documentation changes, but would also cause many different versions of the documentation to be available at the same time.

Hmm, I guess it cannot hurt, but I am not sure whether it has that much of a benefit 🤔 If you want to review the rendered version, I guess you could also just quickly build the documentation locally. Then again, it might be nice to have links pointing to places where the rendering has issues 🤔 I guess it comes down to how easy this is to implement.

As of now, I have not implemented a cleanup mechanism to remove old coverage reports (and possible documentation builds) of merged PRs from the GitHub pages deployment. This could be seen as an advantage (you can see the coverage reports even after the PR was merged), but I'm not sure if this could also have negative implications regarding repository size.

Would it be an option to not deploy GitHub pages via a branch but via an action? I guess then we would not have to worry about repository size at all. Maybe older reports could be stored in the cache for this approach.

[pulsastrix]

Hmm, I guess it cannot hurt, but I am not sure whether it has that much of a benefit 🤔 If you want to review the rendered version, I guess you could also just quickly build the documentation locally. Then again, it might be nice to have links pointing to places where the rendering has issues 🤔 I guess it comes down to how easy this is to implement.

Probably not that complicated, I'll see what I can do.

Would it be an option to not deploy GitHub pages via a branch but via an action? I guess then we would not have to worry about repository size at all. Maybe older reports could be stored in the cache for this approach.

Deploying via an action would (if I understand it correctly) have the disadvantage that we'd only have a single deployment for all branches, i.e., pushing to one of the current branches will override the deployment of the other one.

We could deploy to a different repository, but in order to do so, we would have to create an access token, as the standard GITHUB_TOKEN cannot access other repositories.

[pulsastrix]

On another note, I just noticed that I might have to make some additional changes to properly support PRs from forked repositories, so I'll set this back to the draft state.

[JKRhb]

Deploying via an action would (if I understand it correctly) have the disadvantage that we'd only have a single deployment for all branches, i.e., pushing to one of the current branches will override the deployment of the other one.

Hmm, yeah, I guess in that case we would need to have an action that iterates over all (active) branches/PRs and then create the documentation/coverage reports for all of them. This would probably have the main downside of being slow if there are many branches/PRs.

[falko17]

Quick question to the other maintainers: Do you think it's worth the effort to also build the documentation and push it to GitHub Pages?

I agree with @JKRhb here in that it would be nice to have, but not important enough to warrant spending significant time on, since—AFAICT—this'd only be useful for reviews (and even then, building the documentation locally doesn't take long and isn't that complicated).

[pulsastrix]

This should do it, sorry for filling your inbox with notifications...

• There is now also a build for the documentation.
• The docs and coverage report are now deployed to GitHub Pages using a different repository to avoid bloating the main repository size.
• I have made sure that builds from forks also work, see (DO NOT MERGE) Test CI pipeline for PRs from forked repositories #39.
• Linter suggestions are now always provided as GitHub checks and not as review comments (review comments would require access to this repository's secrets earlier on in the pipeline).
• The README files have been updated to include relevant badges.

To test this PR, I had to temporarily change the default branch, as workflow_run-triggered runs use the version of the workflow file that is provided on the default branch and not the one of the PR's branch.
This is a security feature, as the workflow_run triggered run of report.yml has access to the repository's secrets, see https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/.

[falko17]

Looks good to me! I have just three small comments.

[pulsastrix]

Thanks for the quick review!

Remaining CI pipeline failures are unrelated to this PR (see #38), so I'll go ahead and merge.