CI Notify on failure

[csgui]

Add a job to notify @stacks-network/clarity-wasm team when property testing has failed.

We can also have a Slack integration as a compliment to the automated issue. To be handled in other PR, if the case.

Issue generated as a test: #455

[wileyj]

lgtm

[obycode]

Looks good to me, with a little uncertainty on official policy on third party actions -- @wileyj?

[obycode]

Looks good to me, with a little uncertainty on official policy on third party actions -- @wileyj?

I reviewed the source of that action and it doesn't look like it tries to do anything fishy. Can we lock in that specific version to ensure it remains safe? I remember @wileyj looked at this situation before.

[wileyj]

Looks good to me, with a little uncertainty on official policy on third party actions -- @wileyj?

I reviewed the source of that action and it doesn't look like it tries to do anything fishy. Can we lock in that specific version to ensure it remains safe? I remember @wileyj looked at this situation before.

it all depends really - for the stacks-core repo, we lock any external actions to a specific hash vs a version.
there's no official policy/process - but in general we consider the potential blast radius if an external workflow may behave badly in the future.

on occasion, we've forked actions (usually in the case of unclear maintainer) or simply re-implemented ourselves.
if you think there could be security concerns, we do have a repo: stacks-network/actions we could add anything as a composite action - but again, it's really subjective based on what we think the possible issues may be with a malicious workflow.
example of where we use a hash for an external action: https://github.com/stacks-network/actions/blob/main/stacks-core/cache/build-cache/action.yml#L47

and another where we emulated what an external workflow was doing: https://github.com/stacks-network/actions/blob/main/cleanup/workflows/action.yml

tl;dr: it depends.

[obycode]

I think the main concern would be that a rogue action has access to the secrets and then can do bad things with the Github token, so it's better to be safe.

[obycode]

I like the idea of adding the hash to ensure this version does not change.

[wileyj]

I think the main concern would be that a rogue action has access to the secrets and then can do bad things with the Github token, so it's better to be safe.

indeed - let me look into this a little bit. right now, the workflow is using the org secret, but we can set a new repo secret that is better scoped (i.e. only allow an workflow to create an issue).

however, a lot of the ACL's we'd really like to use are only available for gh enterprise

[wileyj]

i think adding something like this to the workflow would be best: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

you may also try using the secrets.GITHUB_TOKEN which is created for the duration of the worklfow (presumably on behalf of the calling actor), and destroyed after the workflow is complete.

if using an external workflow makes you nervous here, there are options to roll your own to create an issue (curl or the gh tool would both work here):
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow