ci: clean up rust-openssl workflow

[joshuasing]

Clean up existing rust workflow.

Changes:

• Move rust_regress.yml to rust-openssl.yml
• Restrict GitHub Action token permissions to contents: read
• Pin actions/checkout to v4
• Use more common naming schemes
• Tidy up styling
• Add manual workflow_dispatch trigger

[botovq]

+ ./configure + make dist + tar zxvf libressl-*.tar.gz + rm libressl-*.tar.gz + cd libressl-*

Can't all these lines be removed?

[joshuasing]

Yes, I have removed the mentioned lines and it appears to still run properly:
https://github.com/joshuasing/libressl-portable/actions/runs/6809749152/job/18516629522

[busterb]

Might want to check out https://github.com/libressl/portable/actions/runs/6819489823 which is results of the first scheduled run.

[botovq]

On Thu, Nov 09, 2023 at 07:17:54PM -0800, Brent Cook wrote: Might want to check out https://github.com/libressl/portable/actions/runs/6819489823 which is results of the first scheduled run.

I haven't yet had a chance to look at the details of this failure because github helpfully hides them when not logged in, but what I'm most concerned about is that I didn't get notified about it.

[botovq]

Don't these environment variables need to be exported?

[joshuasing]

Hmm, I thought as those are in the same script they should apply to the cargo test line

[botovq]

called `Result::unwrap()` on an `Err` value: ErrorStack([Error { code: 50856204, library: "digital envelope routines", function: "inner_evp_generic_fetch", reason: "unsupported", file: "../crypto/evp/evp_fetch.c", line: 349, data: "Global default library context, Algorithm (SHA1 : 94), Properties (<null>)" }])

inner_evp_generic_fetch is an openssl 3 function that is being called. Presumably because the shell variable isn't picked up by cargo.

[joshuasing]

This exact workflow is somehow working perfectly fine on my fork repository:
https://github.com/joshuasing/libressl-portable/actions/runs/6821208983/job/18551276024 (logs: https://pastes.dev/cgfub1k0TU)

[botovq]

Could you change this into cargo test --verbose, so we can see what's going on please?

[joshuasing]

Sure

[botovq]

The last successful run of this workflow was https://github.com/libressl/portable/actions/runs/7675295067
It has failed for three days now because of Joel's shutdown changes. I am pretty sure I used to get notifications from scheduled CI run failures. Why wasn't I notified? Could you please make sure I get notifications if anything fails in CI?

[busterb]

...

[busterb]

There is some oddity around how notifications for CI failures work.

I think locally, you need to ensure the below setting is enabled at least:

Additionally, it seems to send them to whoever enabled the cron job last
for the workflow?

https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/notifications-for-workflow-runs

[botovq]

Thanks. I have all that set, as far as I can see. What good is scheduled CI if you need to make an effort to see its failures?

Anyway. I suspect I got notifications from my fork, which were now turned off in #991 because of the noise. I'll figure something out.