search

Atleta-network / atleta

https://atleta.network
GNU General Public License v3.0
11 stars 5 forks source link

Workflow for release binaries #146

Closed hrls closed 3 months ago

hrls commented 4 months ago

Closes #109

hrls commented 4 months ago

As far as I can see, the DockerHub release contains no more info than a simple timestamp. It looks like using RuntimeVersion involves some code updates, such a CLI command to call a Runtime API func named version. I'll move on with it. Please let me know if there is some more applicable approach to do this.

ales-tsurko commented 4 months ago

As far as I can see, the DockerHub release contains no more info than a simple timestamp. It looks like using RuntimeVersion involves some code updates, such a CLI command to call a Runtime API func named version. I'll move on with it. Please let me know if there is some more applicable approach to do this.

yeah, we considered simplify things on the start and use timestamps (which is both human readable and inremented). after a little bit more thinking, I think now that it's actually would be better (and easier) to use good old semantic versioning. as RuntimeVersion may not be changed in case of inner node upgrades. we can simply release on tag and tag the releases with a semantic version. we would need to update the release workflow a little (make a release on a tag push).

UPD

but I'm not sure whether we need it for the devnet, because of how often it should be deployed. maybe it would be better to use timestamps as versions for the devnet releases and upload them on push into devnet.

ales-tsurko commented 4 months ago

Also, we need to release runtime as a wasm. It's needed by https://github.com/Atleta-network/atleta-network-deploy/issues/4 And for the wasm it would be great to have RuntimeVersion. But it shouldn't be released each time when the new version of the node is released — as I mentioned, the node could be updated, while the runtime kept unchanged.

hrls commented 4 months ago

Okay, I'll change triggers for this workflow just for release-* tags where wildcard means specific version (no matter semver or just rolling timestamp). For the devnet branch I'll add the ability to a manual start a workflow. This could be used when we want to just trigger devnet release and then the new deploy repo listens to those releases and runs it.

hrls commented 4 months ago

Related to the Runtime WASM binary (blob)…

We can just add this blob to the release archive as well. I prefer to keep automated workflows as stupid as possible as it's hard to decide whether we should run runtime release or not based on some detection logic.

So my proposition is the following: 1) add blob to the release archive as is, 2) then we implement version-extractor utility and mark the blob based on it's output, 3) and then we can add specific logic to the workflow where we will check do we need roll the new runtime release or not;

ales-tsurko commented 4 months ago

Okay, I'll change triggers for this workflow just for release-* tags where wildcard means specific version (no matter semver or just rolling timestamp). For the devnet branch I'll add the ability to a manual start a workflow. This could be used when we want to just trigger devnet release and then the new deploy repo listens to those releases and runs it.

the purpose of devnet is to be able to check changes immediately. so it should be a rolling release - deploy should happen every time there is a push into devnet.

ales-tsurko commented 4 months ago

Related to the Runtime WASM binary (blob)…

We can just add this blob to the release archive as well. I prefer to keep automated workflows as stupid as possible as it's hard to decide whether we should run runtime release or not based on some detection logic.

So my proposition is the following:

  1. add blob to the release archive as is,
  2. then we implement version-extractor utility and mark the blob based on it's output,
  3. and then we can add specific logic to the workflow where we will check do we need roll the new runtime release or not;

let's rather trigger wasm releases manually or based on RuntimeVersion change. having releases for the runtime covered by particular node version even if there are no changes in the runtime is too confusing.

upd I mean, probably it's out of the scope of this PR.

hrls commented 4 months ago

JFYI there is a tool called subwasm. We can probably use it to implement some fancy stuff like this https://docs.substrate.io/reference/how-to-guides/tools/verify-wasm/#compare-two-different-runtimes-of-a-live-chain

hrls commented 4 months ago

We decide to implement CD release for runtime WASM outside this PR. TODO: #147

This workflow will release LICENSE file and atleta-node binary named in as release-branch_or_tag-commit_sha-OS-arch for any push to: testnet and devnet branches, release-v* tag.

hrls commented 4 months ago

TODO @hrls : There is an additional trick – mark as the latest release only the one built on the devnet or testnet branch. This way any other release (for example manually triggered for on the specified branch) will not be marked as the latest.

Edit: done