Automate compilation of binaries and releases

Question

Automate compilation of binaries and releases

Closed this issue 2 years ago · 30 comments

The Problem

I only have access to Windows and Linux platforms.
Rusty Autoclicker should be compatible with macOS but I am unable to compile the macOS binary.
I would have to have all 3 platform binaries in the releases.

Is it possible to automate this process via GitHub actions artifacts?
Ideally the action would produce a draft release that maintainers/collaborators can release manually.

Answer 1 · 2022-09-25T05:07:38.000Z

Yes it is possible, I'm not a rustacean personally but I like playing around with GitHub Actions. Would love to give it a shot.

What do you mean you can't compile the MacOS binary?

Answer 2 · 2022-09-25T05:33:06.000Z

Also is there any reason you're using cargo build over cargo build --release?

Answer 3 · 2022-09-25T05:56:47.000Z

I have no clue what I'm doing with the rust related commands but I have got artifacts uploading, but can't see any executable, shouldn't there be an executable?

Answer 4 · 2022-09-25T06:02:54.000Z

Once we get the executable sorted we can work on using https://github.com/softprops/action-gh-release for the draft releases 👍

Answer 5 · 2022-09-25T16:04:55.000Z

Hey there, thanks for the interest, I can really use the help with this!

Yes it is possible, I'm not a rustacean personally but I like playing around with GitHub Actions. Would love to give it a shot.

What do you mean you can't compile the MacOS binary?

I tried setting up cross compilation but it didn't work out and I do not own a macOS pc so that's why I can't compile it.

Also is there any reason you're using cargo build over cargo build --release?

When I wrote the current github actions, it was purely just to make sure that everything compiles, it wasn't meant to help with the release. The new automate release should indeed use cargo build --release. Good catch!

I have no clue what I'm doing with the rust related commands but I have got artifacts uploading, but can't see any executable, shouldn't there be an executable?

Yeah it should have been there
This is what the folder structure looks like on Windows when I build

Once we get the executable sorted we can work on using https://github.com/softprops/action-gh-release for the draft releases 👍

That looks great, I really like how it can generate a draft and has options for external release notes.
I'm quite new to making releases and I'm not too happy with how I'm doing changelogs right now.
I think I'll make a CHANGLOG.md eventually

Answer 6 · 2022-09-26T07:49:27.000Z

Ok I figured out the issue with the upload, will update the workflow after dinner 👍

Answer 7 · 2022-09-26T12:12:15.000Z

For organizing your workflows, what would you prefer:

artifacts.yml and draft-release.yml that handle artifacts and releases for all platforms in the same workflow
platform specific workflows that handle the artifact upload and draft releases at the same time
platform specific workflows for either the draft releases OR the artifacts and then a designated workflow for all platforms releases OR artifacts

Hope that makes sense 😅. I think it would be best to do number 2 because then the same binaries don't have to be built twice

Answer 8 · 2022-09-26T12:16:13.000Z

The unzipped artifact now looks like this:

The trick was to link the artifact to target/<name of intended architecture>/release

Answer 9 · 2022-09-26T12:43:51.000Z

I have the releaser working on a private test repo, before I implement it on my fork, could you please tell me what triggers you'd like for the draft release to be created. I think if it triggers on every commit that would be a huge amount of needless drafts.
Some examples of conditionals we can put are:

A tag is included for the commit
The commit has a certain keyword in it such as release:
The workflow was triggered by merging into main (don't know how to do this yet but I'm sure i can figure it out)

Answer 10 · 2022-09-26T13:58:29.000Z

For organizing your workflows, what would you prefer:
1. `artifacts.yml` and `draft-release.yml` that handle artifacts and releases for all platforms in the same workflow

2. platform specific workflows that handle the artifact upload and draft releases at the same time

3. platform specific workflows for either the draft releases OR the artifacts and then a designated workflow for all platforms releases OR artifacts
Hope that makes sense 😅. I think it would be best to do number 2 because then the same binaries don't have to be built twice

Yup option 2 seems best at the moment

The unzipped artifact now looks like this:

The trick was to link the artifact to target/<name of intended architecture>/release

Does the release file/artifact contain all of that or only the binary file? (I think the binary file only will be interesting for regular users)

I have the releaser working on a private test repo, before I implement it on my fork, could you please tell me what triggers you'd like for the draft release to be created. I think if it triggers on every commit that would be a huge amount of needless drafts. Some examples of conditionals we can put are:
1. A tag is included for the commit

2. The commit has a certain keyword in it such as `release:`

3. The workflow was triggered by merging into main (don't know how to do this yet but I'm sure i can figure it out)

I'm not expecting things to get too crazy considering the rather simplistic nature of Rusty AutoClicker.

Can we have it on manual (workflow_dispatch), for now and have the code for triggered on PR merged to main commented out please?

Answer 11 · 2022-09-27T07:21:58.000Z

Yup option 2 seems best at the moment

👍

Does the release file/artifact contain all of that or only the binary file? (I think the binary file only will be interesting for regular users)

Fixed, now the zip files will only contain the binary

Can we have it on manual (workflow_dispatch), for now and have the code for triggered on PR merged to main commented out please?

So to confirm this:

the draft-release should only be triggered on workflow_dispatch (while the workflow itself will be triggered on workflow_dispatch OR changes to .rs files)
a conditional that only triggers draft-release after a merge to main should be put but commented out for future use

Answer 12 · 2022-09-27T09:49:06.000Z

Another question:

How does the workflow know what to name the release? Or should I just put a place holder such as [release vX.Y.Z]

Answer 13 · 2022-09-27T13:11:57.000Z

So to confirm this:

the draft-release should only be triggered on workflow_dispatch (while the workflow itself will be triggered on workflow_dispatch OR changes to .rs files)

a conditional that only triggers draft-release after a merge to main should be put but commented out for future use

Yup, the draft-release should be triggered by workflow_dispatch only
I don't understand what you mean by "(while the workflow itself will be triggered on workflow_dispatch OR changes to .rs files)" , is the draft-release an action within the workflow (containing more actions)?
Yes please, it could come in handy in the future!

Another question:

How does the workflow know what to name the release? Or should I just put a place holder such as [release vX.Y.Z]

Can you please try and see if https://github.com/dangdennis/toml-action or similar works? (ideal)
So it can read the version directly from Cargo.toml; the version there is bumped before every release.

Worse come to worse, I read that GitHub actions can read JSON files https://docs.github.com/en/actions/learn-github-actions/expressions#fromjson we could add a release.json to the root folder containing the release version (not ideal)

Answer 14 · 2022-09-27T13:55:11.000Z

Yup, the draft-release should be triggered by workflow_dispatch only
I don't understand what you mean by "(while the workflow itself will be triggered on workflow_dispatch OR changes to .rs files)" , is the draft-release an action within the workflow (containing more actions)?

Ah ok, let me ask you a question then, would you like the release drafting to be done in it's own workflow, or in one of the binary building workflows? Both are possible with some thoughtful design.

Can you please try and see if https://github.com/dangdennis/toml-action or similar works? (ideal)

Certainly, that is definitely possible

I'm going to be a little busy the next few days as I have an AWS exam on Thursday. Hopefully after then I'll have time to complete and perfect the workflows 👍

Answer 15 · 2022-09-27T23:29:30.000Z

Ah ok, let me ask you a question then, would you like the release drafting to be done in it's own workflow, or in one of the binary building workflows? Both are possible with some thoughtful design.

In its own workflow please

Certainly, that is definitely possible

I'm going to be a little busy the next few days as I have an AWS exam on Thursday. Hopefully after then I'll have time to complete and perfect the workflows 👍

No worries at all, good luck! It's actually better for Hacktoberfest if we delay it until the 1st

Answer 16 · 2022-10-14T19:47:30.000Z

@TechWiz-3 Is everything ok?
How can I help?

Answer 17 · 2022-10-15T05:15:14.000Z

Sorry man just been so busy, i'll get onto this soon

Answer 18 · 2022-10-15T10:43:47.000Z

No worries, sure thing

Answer 19 · 2022-11-06T21:53:12.000Z

@MrTanoshii How's the progress on this issue rn? I can try to work on this issue ~~this weekend~~. Seems relatively straightforward to implement.

Answer 20 · 2022-11-06T22:25:17.000Z

Hmm, it's been a while, if you're up for it, by all means, go for it!

Answer 21 · 2022-11-11T21:09:31.000Z

@nozwock

The build failed ;_; https://github.com/MrTanoshii/rusty-autoclicker/actions/runs/3447725966/jobs/5754035996

Is it because it's supposed to zip bin/rusty-autoclicker but this was deleted in Rename binaries [Others]?
Please help

Answer 22 · 2022-11-11T21:14:04.000Z

The build failed ;_; https://github.com/MrTanoshii/rusty-autoclicker/actions/runs/3447725966/jobs/5754035996

Is it because it's supposed to zip bin/rusty-autoclicker but this was deleted in Rename binaries [Others]?
Please help

Really? Weird I'll check

Answer 23 · 2022-11-11T21:32:57.000Z

@MrTanoshii Oops, I'm sorry about, fixed here: #28 (review)
It was due to a typo...I had just copy pasted the workflow from my private repo to the PR branch and forgot about that particular key name being different 😑

Answer 24 · 2022-11-11T21:36:49.000Z

Can you re-merge the changes or something? Don't need a separate PR right?

Answer 25 · 2022-11-11T21:41:18.000Z

Can you re-merge the changes or something? Don't need a separate PR right?

Sorry! I think it will need a new PR.

Answer 26 · 2022-11-11T21:47:04.000Z

Sorry! I think it will need a new PR.

Oh ok, here #29

Answer 27 · 2022-11-11T22:37:29.000Z

Btw @MrTanoshii, I ran into a pretty fatal bug (I'm very surprised no one ran into it yet) with the app but is also easy to fix, will submit the issue tommorow. It's late rn

Answer 28 · 2022-11-11T22:54:13.000Z

Sure thing! The action is working.

I am also running in some issues (I don't think it is github action related). #31

Answer 29 · 2022-11-12T15:27:26.000Z

Issue isn't closed?
Weird, why did this action fail?
Is tar on macOS different than GNU tar? Seems like --remove-files flag is causing issue on macOS...

Answer 30 · 2022-11-13T00:17:07.000Z

Glad you got this done 👍