Check failing with "Resource not accessible by integration"
yoshuawuyts opened this issue · comments
In https://github.com/async-rs/async-std/pull/271/checks?check_run_id=247986116 we're getting an error about clippy failing:
I'm unsure what's causing this. I'd suspect a bad token of sorts, but I don't see how that could be possible. I saw the note in the readme, but this seems distinct also? Do you maybe know what might be going on? Thanks!
I saw the note in the readme, but this seems distinct also?
I think this case is covered by that note, as the pr does have a fork as source branch (sunjay:fromstream-impls)
@bjorn3 ahh okay, I probably misinterpreted it then. It'd be nice if this action could detect whether the check is from another repo, and fall back to regular reporting instead (rather than failing)
Yeah, @bjorn3 is right about the forked repo. We were investigating this problem earlier today with @Luni-4 and I had created a post about this problem at the github forums, but that is pretty much it.
I like an idea about falling back to the old plain stdout reporting, though (thanks, @yoshuawuyts!), that seems like a only reasonable option till Github will handle this problem somehow.
I like an idea about falling back to the old plain stdout reporting, though (thanks, @yoshuawuyts!), that seems like a only reasonable option till Github will handle this problem somehow.
Yep, I agree with this option too. In this way the Github Token isn't used at all for now.
Alright, I added the stdout fallback as was suggested and published it already.
@yoshuawuyts can you restart that check to be sure that everything is okay there?
@svartalf thanks so much!
Though https://github.com/async-rs/async-std/pull/271/checks?check_run_id=249044165 seems like it falls back nicely now, but now also always exits with status code 0 even if clippy checks fail.
@yoshuawuyts right now it is an intended behavior, as the Action returns a non-zero exit code in case if any ICE or errors were found, but warning, note and help message types are considered as a "successful" result.
I was thinking about some kind of strict: true flag, but not sure yet about how should it look in a whole. Would love to hear your ideas about it!
@svartalf oh yeah, strict: true seems like a reasonable solution! -- Generally for cargo check we also like to pass RUSTFLAGS="-D warnings" to reject all warnings; if that's not part of the builder yet.
Riffing on the name slightly; if we were to use "rusty" names for this then -D warnings would probably best be translated to reject_warnings: true.
@yoshuawuyts reject_warnings: true sounds nice!
Here is a contrary thought, since we are already discussing it here: should not the project itself tune the clippy errors via #![deny(clippy::*)] attributes instead? Otherwise local cargo clippy and CI one are going be inconsistent (or callers must be forced to remember proper command to execute each time?)
Also, it is already possible to add -D warnings flag via the args input like this:
- uses: actions-rs/clippy-check@v1
with:
args: --all-targets --all-features -- -D warningsIt kinda looks like a hack, since the args input is just passed to cargo clippy invocation as is, but it is a working hack :)
should not the project itself tune the clippy errors via #![deny(clippy::*)] attributes instead?
So in async-std we used to have this, but switched the flag to only run in CI because we wanted a slightly better cadence during development. E.g. when you're developing features you want to get things to compile, and not bother too much with the warnings much while you're working on it.
Then once you're ready to file a PR you want to have the quality enforced, and ensure that no warnings are merged into the main codebase. I think the inconsistency here is a feature, and overall leads to a much better developer experience!
It's probably possible to set this up through features and configs, but this feels like the kind of thing that having a simple toggle for would allow it to be documented in a single place, easy to use, and in turn make it more accessible to people!
This looks like a tracking issue for annotations: actions/toolkit#186
Annotations seem to now be a thing. At least other actions now seem to be able to place annotations freely without any issues.
Here's how a different Rust action is handling the annotations now (apparently via problem matchers): hecrj/setup-rust-action#14
I guess that's quite different from what is being done here, but might be a decent workaround for now.
Is there a way to enable pull request annotations for PRs made from branches on non-forks? I cut quite a few branches on my repos, and there it would be really good to see the annotations in the PR conversation instead of getting them on the commit itself.
Alternatively, it would be kinda cool to be able to get these PR annotations inline on a bors build. (That does cut a branch on the source repo after all...)
Uh to add a little context, this is now a slightly bigger issue than just forks, as all dependabot PRs now run with read-only permissions due to security issues. We've been having issues with clippy-check ever since this change rolled out, and I haven't been able to figure out why until now.
It would be great if there was some way to optionally suppress permissions-related errors in this action until this whole issue is resolved.
This is the workaround I've put in place for now to run clippy manually when a workflow doesn't have write permissions:
- name: Check workflow permissions
id: check_permissions
uses: scherermichael-oss/action-has-permission@1.0.6
with:
required-permission: write
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Run clippy action to produce annotations
uses: actions-rs/clippy-check@v1
if: steps.check_permissions.outputs.has-permission
with:
args: --all-targets -- -D warnings
token: ${{ secrets.GITHUB_TOKEN }}
- name: Run clippy manually without annotations
if: ${{ !steps.check_permissions.outputs.has-permission }}
run: cargo clippy --all-targets -- -D warnings
Currently, as explained in Keeping your GitHub Actions and workflows secure: Preventing pwn requests, GitHub supports these use cases via two workflows: a pull_request triggered workflow that runs the Clippy checks and stores them somehow (i.e. generates artifacts), and then a workflow_run triggered workflow that gets the results and, because it has R/W access to the repository, it can add lints to the commits. However, using this approach effectively with this action clearly requires more support from the action itself.
seeing this error on PRs that are not from a fork. see https://github.com/jhelovuo/RustDDS/runs/4517901228?check_suite_focus=true#step:4:352
Got a(nother) question: what are the exact permissions required by clippy-check:
Has anyone tried this together with pull_request_target? Maybe that fixes the permission problems.
Update: Nevermind, this is part of the documentation:
Avoid using this event if you need to build or run code from the pull request.
Bumping this, do we still not have annotation support?
I think it's not changing at this point that adding annotations requires write token permission, and giving write token permission to PRs is a security issue. The available resolutions are to use problem matchers or pass data through an artifact to a workflow_run trigger that has write permissions to analyze.
My experience, the failure:
{"reason":"build-finished","success":true}
Finished dev [unoptimized + debuginfo] target(s) in 1m 12s
Clippy results: 0 ICE, 0 errors, 0 warnings, 0 notes, 0 help
Error: Resource not accessible by integration
was because the call to client.checks.create was using a token without enough permissions. The client references this doc which suggests permission checks:write needs to be provided.
Adding a permissions block to the Clippy job like the following resolved the failure for me.
cargo-clippy:
name: Cargo Clippy
runs-on: ubuntu-latest
permissions:
checks: write
needs:
- cargo-build
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cargo Cache
id: cargo-cache
uses: actions/cache@v3
with:
path: |
~/.cargo/.crates.toml
~/.cargo/bin
./target
key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
restore-keys: |
${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
- name: Toolchain
uses: actions-rs/toolchain@v1
with:
components: clippy
profile: minimal
override: true
toolchain: stable
- name: Clippy
uses: actions-rs/clippy-check@v1
with:
args: --workspace -- -D warnings
name: Clippy Results
token: ${{ secrets.GITHUB_TOKEN }}To anyone reading this today: I'd recommend using giraffate/clippy-action instead, which offers a comparable feature set to this action, including lint annotations, and is much better maintained.