Skip to content
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

Add expect-error input to force PR check green on expected failure #1177

Merged
merged 22 commits into from
Aug 16, 2022

Conversation

angelapwen
Copy link
Contributor

@angelapwen angelapwen commented Aug 12, 2022

In #1159 we introduced a PR check to confirm that when the analyze workflow fails, partial debug artifacts are still uploaded. This caused 2 PR checks that always failed with a red X, which was not ideal for user experience.

This change adds an expect-error optional input to the analyze workflow, which is set by default to false. Only in the PR Check that intentionally causes a failure in analyze is it set to true (though it could also be used in future cases where we expect a failing job). If this parameter is true, we do not call core.setFailed(...) on the job so it succeeds.

If expect-error is set in any run not created by this repo, or a fork of it, we throw an error.

If expect-error is set to true, but no error in the run was found, the job fails.

Screen Shot 2022-08-12 at 12 35 50 PM

Merge / deployment checklist

  • Confirm this change is backwards compatible with existing workflows.
  • Confirm the readme has been updated if necessary.
  • Confirm the changelog has been updated if necessary.

@angelapwen angelapwen marked this pull request as ready for review August 12, 2022 10:38
@angelapwen angelapwen requested a review from a team as a code owner August 12, 2022 10:38
@@ -66,6 +66,10 @@ inputs:
default: ${{ github.token }}
matrix:
default: ${{ toJson(matrix) }}
expect-error:
description: For PR checks. If true, the Action will not set Actions status to failure.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May need to make this more descriptive so that our users don't set this to true when they don't mean to? I don't think I see a hidden option for input parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this?

Suggested change
description: For PR checks. If true, the Action will not set Actions status to failure.
description: [Internal] If true, the Action will not set Actions status to failure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, this caused some failures — I wonder if the bracket symbols aren't able to be parsed correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding double quotes around it resolved it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider throwing an error inside the code if this is set but the repo is not github/codeql-action or a fork. (You should be able to get that information from the Actions event context.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added this code — still doing a final test of:

  • that if it's set in another repo, the error throws
  • that if it's set in this repo, the test passes
  • that if it's set in a fork of this repo, the test passes
  • that if it's set in this repo but no error is found, an error indicating this is thrown

@@ -66,6 +66,10 @@ inputs:
default: ${{ github.token }}
matrix:
default: ${{ toJson(matrix) }}
expect-error:
description: For PR checks. If true, the Action will not set Actions status to failure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this?

Suggested change
description: For PR checks. If true, the Action will not set Actions status to failure.
description: [Internal] If true, the Action will not set Actions status to failure.

@@ -183,7 +183,10 @@ async function run() {
} catch (origError) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that if an error isn't thrown, we need to set the job to a failure if this input is set to true.

It's a little more complicated than that since I see there are two places where core.setFailed is being called. Do we need to call both of them? It looks like the one in runWrapper is higher up the call chain. Maybe we don't need the one in run.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that if an error isn't thrown, we need to set the job to a failure if this input is set to true.

I'm a little confused: if an error isn't thrown, then why do we need to set the job to a failure? In that case, the job should succeed and we want that, right? Or do you mean that if we expect-error that there must be an error, otherwise there was a problem? That's interesting. I had interpreted it more like force-success

It's a little more complicated than that since I see there are two places where core.setFailed is being called. Do we need to call both of them? It looks like the one in runWrapper is higher up the call chain. Maybe we don't need the one in run.

I'm not sure either. I can play around with it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or do you mean that if we expect-error that there must be an error, otherwise there was a problem? That's interesting. I had interpreted it more like force-success

That's what I mean. If we expect an error and there is none, then that's an error. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added this logic at the end of the outer try block (indicating that an error was not thrown). Thanks!!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly, I found that the outer try block wasn't very useful. This catch block with origError is where I was able to throw/catch/stop errors appropriately. I removed the duplicate logic from the outer try block because it wasn't doing anything.

analyze/action.yml Outdated Show resolved Hide resolved
src/analyze-action.ts Outdated Show resolved Hide resolved
src/analyze-action.ts Outdated Show resolved Hide resolved
src/analyze-action.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@aeisenberg aeisenberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all the bits are correct floating around somewhere, but there must have been a bad merge and there are some syntax errors.

src/analyze-action.ts Outdated Show resolved Hide resolved
} catch (origError) {
const error =
origError instanceof Error ? origError : new Error(String(origError));
if (
actionsUtil.getOptionalInput("expect-error") === "false" ||
actionsUtil.getOptionalInput("expect-error") !== "true" ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a bad merge here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the failures are expected — I removed the ram: 1 line in the last commit to make sure that if expect-error was true and no error was thrown, that it would throw Error: expect-error input was set to true but no error was thrown.

I'll put the line back now that I have that run 👍

@angelapwen
Copy link
Contributor Author

angelapwen commented Aug 16, 2022

So far I have tested to confirm the following cases:

  • when expect-error is set on a repo that's not this one, expect-error input parameter is for internal use only. It should only be set by codeql-action or a fork. is thrown. (run)
  • when expect-error is set on this repo, and no error is found, expect-error input was set to true but no error was thrown. is thrown. (run)
  • when expect-error is set on this repo and an error is thrown, the job succeeds and is green (run)

I will test to make sure it does the right things in a fork and update.

@angelapwen
Copy link
Contributor Author

The fork logic works 👍 (run)

I will do some comment and commit cleanup.

@angelapwen angelapwen requested a review from aeisenberg August 16, 2022 22:26
Copy link
Contributor

@aeisenberg aeisenberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good. It's a nice and simple solution you came up with in the end.

@angelapwen
Copy link
Contributor Author

Thank you! I forgot to remove a couple of core.info() debug lines. Will remove them now, squash and merge, and then add these PR checks to the required set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants