Closed MrTanoshii closed 1 year ago
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?
Also is there any reason you're using cargo build
over cargo build --release
?
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?
Once we get the executable sorted we can work on using https://github.com/softprops/action-gh-release for the draft releases 👍
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
overcargo 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
Ok I figured out the issue with the upload, will update the workflow after dinner 👍
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 workflowHope 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
The unzipped artifact now looks like this:
The trick was to link the artifact to target/<name of intended architecture>/release
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:
release:
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?
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:
workflow_dispatch
(while the workflow itself will be triggered on workflow_dispatch
OR changes to .rs
files)draft-release
after a merge to main should be put but commented out for future useAnother 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]
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)
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 👍
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
@TechWiz-3 Is everything ok? How can I help?
Sorry man just been so busy, i'll get onto this soon
No worries, sure thing
@MrTanoshii How's the progress on this issue rn? I can try to work on this issue this weekend. Seems relatively straightforward to implement.
Hmm, it's been a while, if you're up for it, by all means, go for it!
@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
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 inRename binaries [Others]
? Please help
Really? Weird I'll check
@MrTanoshii Oops, I'm sorry about, fixed here: https://github.com/MrTanoshii/rusty-autoclicker/pull/28#pullrequestreview-1177875702 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 :expressionless:
Can you re-merge the changes or something? Don't need a separate PR right?
Can you re-merge the changes or something? Don't need a separate PR right?
Sorry! I think it will need a new PR.
Sorry! I think it will need a new PR.
Oh ok, here #29
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
Sure thing! The action is working.
I am also running in some issues (I don't think it is github action related). #31
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...
Glad you got this done 👍
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.