| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Thank you for your PR. This is looking really good. I have a few questions inline and suggestions inline.
We will also need to create an integration test for this to ensure that the new inputs are working as expected in real workflows. I'm not sure if you will be able to run them due to restrictions on running CI in forks. I'll figure out how to proceed later.
Sorry, something went wrong.
| const ref = refInput || getRequiredEnvParam("GITHUB_REF"); | ||
| const sha = getOptionalInput("sha") || getRequiredEnvParam("GITHUB_SHA"); |
There was a problem hiding this comment.
It should probably be an error if only one of these inputs are specified.
Also, I'm not sure what would happen if you specify a SHA that is not part of the current branch. Hopefully, code scanning would error out..
Sorry, something went wrong.
There was a problem hiding this comment.
I've added a check that throws an error message, and a unit test to confirm it works. Integration test to come with the rest of the integration tests.
I was initially targeting the upload-sarif action when I added this, so I did really see it as two arbitrary values provided by the user, who would ultimately be responsible to confirm their validity.
I can see two ways to handle this:
a. I can add an integration test for this specific use case, which would test that the code scanning would error out if an invalid ref is provided. If the error message is meaningful and relevant, we can rely on it.
b. I can add a check using git branch ${ref} --contains ${sha} in getRef(), with a fallback if the git command can't be called (see line 86). I would of course add the corresponding unit/integration tests.
For 2., I would prefer option b. This way, we don't have to rely on the underlying scanner. What's your preferred solution?
Sorry, something went wrong.
There was a problem hiding this comment.
EDIT: Option 1 would not be possible, because I realized integration tests can only be positive with the current setup.
So, I can either leave it as-is, without a test, or use option b.
Sorry, something went wrong.
|
Please include the compiled sources (*.js and *.map files) in this PR. Because of the way actions are run, all build artifacts must be checked into the repo. |
Sorry, something went wrong.
|
Hi @aeisenberg! Thanks for your feedback, I've included the compiled sources and fixed most inline suggestions. I am trying to fix the integration tests, in the meantime there is one question remaining in inline suggestions. Can you approve the workflows here please (as I am a first time contributor, Github blocks them)? FYI, Integration tests run in my fork. I had to enable workflows, then I created a draft PR in there just so workflows are executed. This information might be useful for future contributors. |
Sorry, something went wrong.
|
All checks are green in my Draft, so as soon as running workflows is approved I think this can go forward. |
Sorry, something went wrong.
There was a problem hiding this comment.
This is looking really good. I'm running the CI checks again. Hopefully, they will all pass. Just one minor question inline, but it's not a blocker.
Sorry, something went wrong.
Code looks good. Waiting for CI checks to pass.
|
Everything looks good, but the new CI jobs are failing. I'm digging in to try to figure out why. |
Sorry, something went wrong.
|
sendStatusReport doesn't respect TEST_MODE like some other functions do, not sure why it is getting called here but it appears that the test doesn't have permissions to do a PUT against https://api.github.com/repos/github/codeql-action/code-scanning/analysis/status |
Sorry, something went wrong.
@benmoss Should I add a TEST_MODE for sendStatusReport or something? |
Sorry, something went wrong.
That's right, but it doesn't explain why similar integration tests, like the go autobuilder tests are passing. I am fairly certain they are uploading status reports as well. The same job, when run in @cw-acroteau's non-forked PR is passing. |
Sorry, something went wrong.
|
In the non-forked version, I see that the permissions block is more permissive, which explains why it is passing there. The permissions block for the runs in this repo, you can see that all permissions are read. But, it's the same se as in the go autobuilder tests. So, I am still confused. Perhaps, the go autobuilder tests are not sending the status report somehow. |
Sorry, something went wrong.
|
Now things are starting to become clear. If I explicitly add security-events: write then the failing workflows will pass. The difference between the failing workflows and the passing ones is that the failing ones use a value for the ref property of the upload status report that is different from that of the PR. Upload status report is an internal API endpoint for telemetry into code scanning. I don't know if it is a bug that the endpoint sometimes accepts requests from user agents that do not have security-events: write permissions. I'm communicating with the team that maintains this part of the API. Regardless, I think our test workflows should have this permission anyway. Here is what I propose:
Thanks for helping me find this bug (or at least odd inconsistency) in the action. |
Sorry, something went wrong.
Ensure that all workflows are able to write security events.
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
Hi @aeisenberg ! I just did that, hope everything is fine. Once again, the workflows won't run. I don't know what it takes for Github to consider me as not a "first-time contributor", but you'll need to approve the runs again. I'll wait for this, to confirm that the workflows will pass. If there's an issue I'll try to fix it. Thanks! |
Sorry, something went wrong.
|
Hi again @aeisenberg ! Can you please check if the checks are okay in a copy similar to #902 please? It fails here because of "RequestError [HttpError]: Resource not accessible by integration", but it might be due to the fork. |
Sorry, something went wrong.
|
Oh sorry I did a git rebase, and not changed the base branch. I thought this was what you meant. |
Sorry, something went wrong.
|
No problem. I wasn't clear about it. I changed the branch and it all looks good. Yes, the reason why the new workflows are failing is because the security-events permission is always downgraded to read for forks. I don't think it will be possible to get it to pass from a fork. I'm in discussion with the API maintainers to figure out if we should avoid uploading status reports for integration tests. This should allow your integration tests to pass. |
Sorry, something went wrong.
|
They are in Europe, so I probably won't hear anything until tomorrow. |
Sorry, something went wrong.
|
PRs from forks will always have their security-events permission downgraded to read. This makes sense because we don't want malicious PRs to come around and tamper with the security alerts for refs they are not associated with. There is an exception to this. a PR from a fork can write security events to resources associated with that PR only. This allows the PR to report security concerns about itself without giving it the ability to overwrite other refs. What this means is that using the standard PR workflow, these new ref and sha inputs will not be able to work in forks. We will need to document this accordingly. It looks like there are ways around this using pull_request_target or possibly [Send write tokens to workflows from pull requests[(https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks). I haven't tried out either of these solutions yet, but they will probably work. However, there are added security considerations with this. What this means is that we need to rebase on the latest tip of the aeisenberg/permissions in this PR (I'll do that shortly) and update the documentation of the inputs to point out the limitation with forks. This PR can then be merged. Later, we can work on some proper documentation on how to use these inputs in forks. |
Sorry, something went wrong.
|
I created a PR in your repo for these changes. If you are happy with them, please merge and then I can merge here. |
Sorry, something went wrong.
|
This PR should not have been closed. It should have been retargeted to main. Let me see what happened. |
Sorry, something went wrong.
|
@cw-acroteau I'm very sorry, but could you create a new PR targeting main? For some reason when #902 was merged, this PR was closed. Instead it should have been retargeted against main. |
Sorry, something went wrong.
@aeisenberg Please see #904 |
Sorry, something went wrong.
Move a couple of entries for #889 that should have been in the unreleased section but were inadvertently moved into the 1.0.31 release.
| Back | FazBrowse Home | New Git URL |
Merge / deployment checklist
This PR might be useful for those facing #796 by allowing to specify a ref, but is NOT a direct fix for it.