Add upload to registry workflow for foundry_std

[THenry14]

Closes #2344
Closes #2463

This PR is a part of the stack:
-- Add missing info recommended for package uploads (#2460)
--> Add github action workflow for automatic registry uploads during release (This PR)

Introduced changes

• Updates github workflow to also upload std libraries to scarbs registry during release
• Sets snforge_scarb_plugin to specific version downloadable from the registry, as required by scarb

Checklist

• Linked relevant issue
• Updated relevant documentation
• Added relevant tests
• Performed self-review of the code
• Added changes to CHANGELOG.md

[franciszekjob]

Blocked by software-mansion/scarb#1605

[kkawula]

It needs clarification, but plugins weren't correctly handled by scarb until software-mansion/scarb#1712 was merged, I suppose that it will be needed to update scarb version in the entire project.
In the earlier versions scarb had problem with access to the cache in database which caused dead lock.
CI to lookup: https://github.com/foundry-rs/starknet-foundry/actions/runs/11577774705

edit: The scarb version in the project can probably stay as it is but while package upload dependency in snforge_std/Scarb.toml should be manually switched to registry dependency and after upload reverted.

[maciektr]

It needs clarification, but plugins weren't correctly handled by scarb until software-mansion/scarb#1712 was merged, I suppose that it will be needed to update scarb version in the entire project.

It shouldn't have anything to do with uploading packages though

[DelevoXDG]

Partial review, please re-request when ready 👍🏻

[DelevoXDG]

Is this step necessary?

We implemented this for publishing Scarb plugins because their version matches the Cairo version. Since multiple Scarb versions can correspond to a single Cairo version, running the workflow with every Scarb release could cause errors by publishing plugins with the same version.

Afaik, this doesn’t apply to snfoundry plugins because their version isn’t tied to any Cairo version. Normally, the workflow should only be triggered once per tag.

[cptartur]

We might decouple foundry plugin version from foundry itself so it might be the case that for consecutive foundry releases, plugin version will stay the same.

So we have to make sure we don't reupload the plugin to the registry in these cases.

[kkawula]

Sometimes we patch plugin, without release then we would like to publish it and sometimes we will not do release plugin together with snforge_std and sncast_std, we want to set it on 1.0.0 and keep it until there are changes, and then it would fail the workflow and CI will be red at the release

[DelevoXDG]

As I pointed out offline, if you're going in the direction of decoupling plugin from foundry itself, it seems to me it a separate workflow should be considered

[kkawula]

It is one of the opportunities, but isn't it good enough? @cptartur

[THenry14]

Similarly to @DelevoXDG , I would probably be in favour of splitting release flows for macros and standard libraries as well.

My understanding is that the plugin won't necessarily follow the *_std version, so it may make sense to release it independently. For this manual workflow dispatch only is good enough. Most of logic from this file is fine, though you wouldn't need anything from this step (I mean the check-versions, which I find very hacky) so I'd actually argue it could become far simpler.

Having this, we could probably incorporate *_std upload to the release.yml workflow, as it seems to me this is more natural place for this. We already verify the version there, so chances are we do not need any further modifications - we could probably just add a new job (standard-libraries-release, or scarbs-release or sth) that will set the plugin version (this is unnecessary if you decide to set the version in Scarb.toml in repo) and use scarb to publish and call it a day. No need to check versions against the registry, verify what should/should not be published etc.

Thoughts?

[kkawula]

I generally agree with you, but I can still see a few problems we could encounter. In scenario where this workflow is splited and moved to release we can get error while releasing new versions of _std and plugins simultaneously. Then plugin should be then uploaded before _std, to make snforge_std dependency working. As other job in can be made sequential, but if we like to provide workflow_dispatcher then its generates a lot of unnecessary boilerplate code (ifs) in entire workflow, because we can’t actually specify exact job to run on dispatch. In scenario of two different workflows it actually can’t be made sequential and then we can only hope that plugin will be uploaded first.

[THenry14]

In scenario where this workflow is splited and moved to release we can get error while releasing new versions of _std and plugins simultaneously

Well I do not think we necessarily need to release macro in the same time we release package, and because of that workflow_dispatch would be ideal. I can easily imagine macro not being updated for months, or be updated multiple times during one week when we do not want to release new snfoundry version.

If you wanted to the release workflow could call the plugin publish workflow, to have the functionality we're aiming for and be sure that the release operations are indeed sequential.

[DelevoXDG]

If you wanted to the release workflow could call the plugin publish workflow, to have the functionality we're aiming for and be sure that the release operations are indeed sequential.

That's how I see it as well, we should have:

1. Plugin publish workflow with workflow_dispatch and workflow_call
2. Foundry publish workflow on release and workflow_dispatch. It should first should check if plugin is up to date in first job and re-use the first workflow if necessary to upload the plugin, and release the foundry libs afterwards

As other job in can be made sequential, but if we like to provide workflow_dispatcher then its generates a lot of unnecessary boilerplate code (ifs) in entire workflow, because we can’t actually specify exact job to run on dispatch.

Do you have any specific examples of why that might be the case? 🤔 I don't think this should really cause any boilerplate or significantly more ifs than we have now

[kkawula]

Seems convincing. Updated.

[cptartur]

We might decouple foundry plugin version from foundry itself so it might be the case that for consecutive foundry releases, plugin version will stay the same.

So we have to make sure we don't reupload the plugin to the registry in these cases.

[cptartur]

@THenry14 Can you please review as well? I know it's technically your PR but it's changed a bit 😅

[THenry14]

Similarly to @DelevoXDG , I would probably be in favour of splitting release flows for macros and standard libraries as well.

My understanding is that the plugin won't necessarily follow the *_std version, so it may make sense to release it independently. For this manual workflow dispatch only is good enough. Most of logic from this file is fine, though you wouldn't need anything from this step (I mean the check-versions, which I find very hacky) so I'd actually argue it could become far simpler.

Having this, we could probably incorporate *_std upload to the release.yml workflow, as it seems to me this is more natural place for this. We already verify the version there, so chances are we do not need any further modifications - we could probably just add a new job (standard-libraries-release, or scarbs-release or sth) that will set the plugin version (this is unnecessary if you decide to set the version in Scarb.toml in repo) and use scarb to publish and call it a day. No need to check versions against the registry, verify what should/should not be published etc.

Thoughts?

[THenry14]

great job mate

[DelevoXDG]

LGTM 👍🏻

[kkawula]