ci: update release process with release-please

[antonbaliasnikov]

What 💻

• Add release-please configuration and workflows
• Update Docker image with cargo chef build stage that allows the proper layers caching improving docker image building time from ~30 min to ~15 min.
• Add GH attestations to Docker images as well as for binaries
• Add the capability to manually trigger binary release workflow to generate a prerelease for testing purposes
• Create only one attestation for all binaries instead of individual attestation for each binary per platform.

[dutterbutter]

@antonbaliasnikov were you able to test successfully in a fork by any chance? I suppose this will also Closes #474

[antonbaliasnikov]

@antonbaliasnikov were you able to test successfully in a fork by any chance? I suppose this will also Closes #474

@dutterbutter , I've tested it in this PR by enabling pull_request target and making sure that docker and binaries are successfully built.

In the fork, I've tested release-please as well, here is a next release PR example:
antonbaliasnikov#9

But I will test a bit more as I found see some issues with release-please tagging.
Update: it was related to the default token that by some reason was not able to properly add labels in PRs even with the right permission settings. What is more interesting that absolutely identical settings are working in my foundry-zksync fork with no issues.

I suppose this will also Closes #474
Yes, it will. Is is aligned with the issue through the git branch name.

But we need to discuss minor details with you and @itegulov about the flow. Because release-please will always create the release first, and only then we start jobs to add binaries and publish docker images. We can re-try them if they fail, but anyway it would be nice to discuss the flow we would like to see.

[itegulov]

Because release-please will always create the release first, and only then we start jobs to add binaries and publish docker images. We can re-try them if they fail, but anyway it would be nice to discuss the flow we would like to see.

Can't we make release-please create preleases where the corresponding docker tag would be prerelease-vx.y.z and then once we ensure everything is buildable/pushable, we promote prerelease that triggers retagging from prelease-vx.y.z to vx.y.z which should be infallible?

That being said I don't want to complicate the flow too much so I think it is fine to leave it as is if there are no reasonable options. Let's just make sure that job failures are visible, I don't want them to be "swallowed" silently. I am guessing at least the person who pressed the merge button on the PR would get an email notification about job failure, correct?

[antonbaliasnikov]

Because release-please will always create the release first, and only then we start jobs to add binaries and publish docker images. We can re-try them if they fail, but anyway it would be nice to discuss the flow we would like to see.

Can't we make release-please create preleases where the corresponding docker tag would be prerelease-vx.y.z and then once we ensure everything is buildable/pushable, we promote prerelease that triggers retagging from prelease-vx.y.z to vx.y.z which should be infallible?

That being said I don't want to complicate the flow too much so I think it is fine to leave it as is if there are no reasonable options. Let's just make sure that job failures are visible, I don't want them to be "swallowed" silently. I am guessing at least the person who pressed the merge button on the PR would get an email notification about job failure, correct?

Prereleases are barely supported with release-please.
Although I think that we can do better and improve on the process, I suggest we do it iteratively. Let's merge this flow and I'll check prereleases and possibilities here separately if you don't mind.

For now, yes, visibility will be highly better and email notifications + Slack notifications about failures should be sent.

[antonbaliasnikov]

@itegulov , please, take another look. I fixed all issues.

[itegulov]

LGTM! Left a small nit but feel free to merge as is

[itegulov]

Nit: do we even need concurrency groups anymore?

[antonbaliasnikov]

Yeah, I guess it can be removed in this case.