-
Notifications
You must be signed in to change notification settings - Fork 329
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds ref and SHA as inputs, and sarif-id as output #889
Adds ref and SHA as inputs, and sarif-id as output #889
Conversation
51971d1
to
1f8caea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/actions-util.ts
Outdated
const ref = refInput || getRequiredEnvParam("GITHUB_REF"); | ||
const sha = getOptionalInput("sha") || getRequiredEnvParam("GITHUB_SHA"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
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 usinggit 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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Please include the compiled sources ( |
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. |
9674ae4
to
f1ca338
Compare
All checks are green in my Draft, so as soon as running workflows is approved I think this can go forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
sendStatusReport doesn't respect |
@benmoss Should I add a TEST_MODE for sendStatusReport or something? |
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. |
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 So, I am still confused. Perhaps, the go autobuilder tests are not sending the status report somehow. |
Now things are starting to become clear. If I explicitly add 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. |
Ensure that all workflows are able to write security events.
Co-authored-by: Andrew Eisenberg <[email protected]>
32d8387
to
9f36b75
Compare
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! |
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. |
Oh sorry I did a |
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 |
They are in Europe, so I probably won't hear anything until tomorrow. |
0dd07df
to
36419a7
Compare
PRs from forks will always have their 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 It looks like there are ways around this using What this means is that we need to rebase on the latest tip of the |
I created a PR in your repo for these changes. If you are happy with them, please merge and then I can merge here. |
This PR should not have been closed. It should have been retargeted to main. Let me see what happened. |
@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. |
@aeisenberg Please see #904 |
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.
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.