Complete rework of our CI

[AnotherDaniel]

This is to address #51, and will be a multi-stage PR (a few individual commits with change sets building up the whole picture).

Step 1 - enable cargo-deny, adding deny.toml, and changing a build.rs dep for avoid strange licensed crates in our dep tree

Step 2 - remove Cargo.lock from our .gitignore and add a couple of template files to enable cargo-about

Step 3 - introduce the all-new github workflows

[PLeVasseur]

👍

Was about to ask for this yesterday on the issue, but you beat me to the punch 🙂

[PLeVasseur]

Hey @AnotherDaniel -- opened an issue for adding cross-compiling to the CI/CD: #73

Do you think we should tackle that as a part of this PR or a new one after this one merges?

[AnotherDaniel]

This workspace setup with locked-in required workflows is driving me up the wall in this context here. Who has admin rights to this repo and can just fix this? Should be related to this feature: https://github.blog/2023-01-10-introducing-required-workflows-and-configuration-variables-to-github-actions/

[PLeVasseur]

Who has admin rights to this repo and can just fix this? Should be related to this feature: https://github.blog/2023-01-10-introducing-required-workflows-and-configuration-variables-to-github-actions/

I dunno if committers get admin rights. If so => @sophokles73, if not => @stevenhartley

[stevenhartley]

Who has admin rights to this repo and can just fix this? Should be related to this feature: https://github.blog/2023-01-10-introducing-required-workflows-and-configuration-variables-to-github-actions/

I dunno if committers get admin rights. If so => @sophokles73, if not => @stevenhartley

Hi @AnotherDaniel , that is me and I think anyone else. We use branch protection rules that require certain workflows to be successful to run. These rules are turned on/off using otterdog in the https://github.com/eclipse-uprotocol/.eclipsefdn project. As you can see in https://github.com/eclipse-uprotocol/.eclipsefdn/blob/main/otterdog/eclipse-uprotocol.jsonnet#L355 we require three workflows to be successful so if you change the names of the workflows (or delete them), the branch protection rules will fail. We can temporarily turn them off, fix the workflows, then turn them back on if you like? It is a 10 min change for me, let me know if you want me to do that for your project. You can also fork this project, make the change, then create a PR to merge it back in.

[AnotherDaniel]

@stevenhartley then I think the path forward would be to turn off these rules, merge this PR and turn the new ones on again?

Would work for me, I can't do any of these things but would pick things up once these workflows are active.
I can do the otterdog change for you to copy-paste, but earliest tomorrow...

[stevenhartley]

Change is pending, once merge you only have to retrigger the change by pushing something (black space or something): eclipse-uprotocol/.eclipsefdn#46

[stevenhartley]

@AnotherDaniel it is all passing and looking great, please let me know if it is ready to merge or if you would like others to chime in as well.

[AnotherDaniel]

I think this can be merged - already did a review with @sophokles73 earlier today, and incorporated feedback. In any case this is an improvement to what we had before. More goodness can surely be added, but in subsequent PRs...

[PLeVasseur]

Impressive stuff! Thanks @AnotherDaniel 🙂

I must admit, I am not as knowledgeable as you on the CI, but this looks comprehensive

[AnotherDaniel]

All review comments implemented

[sophokles73]

LGTM

[sophokles73]

@AnotherDaniel do you want to squash again or shall I merge the PR as is?

[AnotherDaniel]

Ah, merge it as is - commit history is reasonably clear I'd say.