ci: gnoland release pipeline

[0xmemorygrinder]

This PR adds a cd pipeline to create a release for all platform and architectures of tooling binaries (gnokey, gnoland and gnoweb).

This solves the issue #1834

Currently the CD is triggered by a push on master and can be triggered manually but let me know if it needs to be changed to a cron or simply manually.

You can check the releases on my fork repository to see that it does work as intended.

From a design perspective, I chose to extract the build logic to a reusable workflow (separate file) as this job can be reused in future pipelines.

[0xmemorygrinder]

Hello @, first of all thank you for your feedback.

If I understand correctly your comment I should :

• modify monthly-snapshot to add my logic instead of creating a spearate workflow
• change the release and tag name to `v{version or 0.0.1}-dev-{snapshot_date}
• also create a docker image and publish it on ghcr in a separate workflow
• make the workflow also run on tag creation
• mark the release as pre-release

Can you confirm this ?

Thanks in advance for your answer

[0xmemorygrinder]

About the docker images, isn't the docker.yml workflow already doing the job ?

[thehowl]

Hello @, first of all thank you for your feedback.

If I understand correctly your comment I should :

* modify `monthly-snapshot` to add my logic instead of creating a spearate workflow

Yes

* change the release and tag name to `v{version or 0.0.1}-dev-{snapshot_date}

Yes; this is the format already used by monthly-snapshot; (you'd have to add the "version detection")

* also create a docker image and publish it on ghcr in a separate workflow

Yes, to answer your follow-up comment, this is done by the existing workflow; however, it will only work publish docker images with gno:latest and gno:<commit hash>.

What I'm saying is that, you should modify this workflow so that it works when publishing a new tag; and when that happens, the image gno:<tag name> (and other ones, like gnoland-slim) are published with the tag name.

This way, we'll eventually be able to pull images through docker using the tag names, rather than having to pinpoint a commit hash. (docker pull ghcr.io/gnolang/gno:v0.0.1-dev.2024.05.01)

(Note: on second thought, as I mentioned here, this can be done on the existing docker workflow, using some conditionals like the ones we already have for pull_request on the same workflow).

* make the workflow also run on tag creation

* mark the release as pre-release

Not pre-release (this is already done), but as draft. Pre-release = pre-v1.0.0; draft = has to be manually reviewed by a core team member before publishing.

Hope that helps. Don't hesitate to ask anything else :)

[0xmemorygrinder]

Thank you for your answer, just a few more question to be sure that I'll be aligned with your expectations :

• How should the version detection work for the release piepline ? I take the last release made and extract the latest version ?
• Only the docker workflow should be triggered by tags ? Because if the release one has to be too there will be an infinite triggering
• Does the release workflow needs to be triggered by a push or a cron ?

[thehowl]

• How should the version detection work for the release piepline ? I take the last release made and extract the latest version ?

Take the last tag (this can probably be done also with git), then sed 's/-[^-]*$//g'

• Only the docker workflow should be triggered by tags ? Because if the release one has to be too there will be an infinite triggering

Yes:

• Snapshot workflow creates the draft release
• Draft release is published, becomes a tag
• Tag triggers docker workflow and pushes the adequate image

Should be no infinite triggering AFAIK

• Does the release workflow needs to be triggered by a push or a cron ?

Just a monthly cron; or workflow dispatch (manual action). These should already be the conditions for monthly_snapshot.

[0xmemorygrinder]

I implemented the above recommendations. You can check on my fork that the releases and docker images are correctly created. The release are drafts, I just published some of them to test the docker pipeline

[zivkovicmilos]

@0xmemorygrinder

Thank you for the contribution 🙏

We've had this internally in the pipeline for some time, along with other fixes with #2101. I'll close out this PR to avoid duplicate work, but I want to thank you for taking the time to open up the PR and address @thehowl's comments.

I'll make sure we find a common effort you can tackle ASAP, that's also important for the team's test4 effort