Update guide at https://dylananthony.com/blog/how-to-write-a-github-action-in-rust/?

[CramBL]

Hi I'm trying to get started writing actions in Rust, thanks for your guide and this template.

I came across your guide at https://dylananthony.com/blog/how-to-write-a-github-action-in-rust/ but it is a little outdated and I got confused because of the mentions of docker but there's no docker in the generated template. Do you have an updated guide somewhere? If not then it could be helpful for future readers if you add a note/warning that the guide is outdated.

[dbanty]

I did write a little about it in https://dylananthony.com/blog/even-better-github-actions-in-rust/ . You're right I definitely need to update the old post as well!

Let me know how your actions go and if you find anything that should be added here!

[CramBL]

Hi again, implementing the action is going well, I changed the release action to only specify target for the ubuntu-latest runner. On macos and windows it should just build for the native platform as it will be executing on that platform anyways (or am I missing something?).

Other than that my changes have mainly just been for the specific needs that my action has, it doesn't generalize well.

• One thing I've wondered is why the template uses such an old version of Rust?

And a bigger thing: Most consumers of actions ends up specifying e.g. action-foo@v1 or even action-foo@master both of which this template doesn't support. If I'm not mistaken, this implementation requires consumers to specify the exact version by tag, and specifying SHAs is not an option (this can be a deal breaker for many).

I'm thinking that I'll have to implement that logic, but it will be some pretty messy powershell scripting if I extend the existing solution. And of course you wouldn't be able to specify any SHA, it would have to match a release, and if a user specifies @latest or @master it should then default to the latest release. Unfortunately, the Github Actions' LSP won't be able to understand that when linting a workflow yaml file which makes the experience a bit worse than usual.

[CramBL]

Regarding the last point. I rewrote the 'get_action_id' step in bash and allowed setting "@latest" as a special case. You might not like that approach. Changes here: https://github.com/CramBL/dependabot-changelog-writer/pull/19/files

EDIT: Nevermind that doesn't work, I misunderstood how actions work.

EDIT2: Just changed latest to "trunk" (my default branch) and then handle when the final component is "trunk" in the get_action_id step

[reneleonhardt]

@dbanty Thank you for this cool action (template)!

But I didn't understand why you have to force the user to choose and update to a specific release.

First, instead of tracking a constantly-evolving v1 branch, consumers of the action will target a particular GitHub Release where they can download artifacts.

Git tags and GitHub releases can just be updated like Docker image tags:

• Tag, build and release v1.2.3
• Replace v1 tag and release with v1.2.3 binary for users who like to use the floating tag @v1

And one other thing, why would you download a specific release from within the same release? 😅
Wouldn't it be easier and faster to commit and distribute the v1.2.3 binary inside the release and just run it?
Then only multiple architectures would have to be built, and later selected at runtime.
I mean... you're already doing that in the last step anyway 😉

./${{ runner.os }}/${{ env.binary_name }}

${{ env.binary_name }} would just be static (no placeholder / variable needed).

[dbanty]

But I didn't understand why you have to force the user to choose and update to a specific release.

It's generally considered best practice to pin to a single version of an action and then update it with renovate/dependabot rather than letting it auto-update (with @v1 or whatever) so you can test changes that are made before adopting them (and choose not to adopt them). In fact, GitHub themselves recommend pinning to shas, but that seems too arduous 😅.

But I like the idea of giving users the choice by also updating a major tag.

Wouldn't it be easier and faster to commit and distribute the v1.2.3 binary inside the release and just run it?

I assume it would actually be slower, since every execution of the action would download the binaries for every platform, rather than just the platform required. Committing binaries to Git is generally discouraged, largely for performance reasons. If you want to try it out experimentally, though, let me know how it goes!