Create official Rust setup GitHub Action?

[jcbhmr]

Problem you are trying to solve

There's a lot of different Rust setup actions on GitHub Actions Marketplace: https://github.com/marketplace?type=actions&query=setup+rust+

This dilutes the "truly good" ones because there's no well-known "good" one. The @actions-rs -- the most comprehensive org with the most users it seemed -- lead maintainer seems to be no longer active, and there's not really a good "best choice" replacement that I could find.

In short, the ecosystem is splintered. This is bad for beginners like me who just want to install the latest Rust version. (can you tell I'm a bit miffed? 🤣) Similar to how Deno has an official https://github.com/denoland/setup-deno action and Ruby has https://github.com/ruby/setup-ruby and so on, I think that some kind of setup-rust action would be a good idea.

I don't know if this is the right place to suggest such a thing, but I figured: hey, it's worth a shot!

Solution you'd like

If nothing else and this idea is out-of-scope for maintenance reasons, I'd at least like to see some kind of documentation pointer to 1 or 2 recommended GitHub Actions on maybe https://rustup.rs/ (cause that's where you go to install rust, right?) or maybe somewhere else? idk

If it's possible, you might also be able to convince @actions 👈 the https://github.com/actions org to add a setup-rust action. idk about that tho, that's even more far-fetched than a @rust-lang/setup-rust action...

I think it would be in the realm of plausibility to ask one of the various action authors 👆 from that big list (or even more than one of you could politically manage it) to bring the best action under the @rust-lang umbrella. That might actually be the most practical idea? 🤔 Or maybe not idk.

Notes

Sorry if I'm asking about this in the wrong place. Or if this idea is vastly out of scope. I just really think that having one good way to do this very common thing is a good idea.

Heck, even some of the @rust-lang repositories have this same issue! 😱

https://github.com/rust-lang/libc/blob/fab4a56f7265333f25bd6484784865c7bf513efa/.github/workflows/main.yml#L24-L29

    steps:
      - uses: actions/checkout@v3
      - name: Setup Rust toolchain
        run: TARGET=${{ matrix.target }} sh ./ci/install-rust.sh  # 👈🔴🔴
      - name: Execute run-docker.sh
        run: LIBC_CI=1 sh ./ci/run-docker.sh ${{ matrix.target }}

And there's 90+ matches for a search of "rustup" used in GitHub Actions for @rust-lang: https://github.com/search?q=org%3Arust-lang+rustup+%28path%3A.github%2Fworkflows%2F*.yml+OR+path%3A.github%2Fworkflows%2F*.yaml%29&type=code

👆 this is the kinda thing that I'd love for an official @rust-lang/setup-rust or @rust-lang/setup-rustup or something action to solve.

[dawnofmidnight]

I don't think this is necessary because, as visible in the rust-lang/rust-analyzer repository, rustup seems to be installed by default on the github actions runners. There's no rustup installation step there.

https://github.com/rust-lang/rust-analyzer/blob/99718d0c8bc5aadd993acdcabc1778fc7b5cc572/.github/workflows/ci.yaml#L63-L67

[rbtcollins]

I think we have a lot of history out there as things have evolved over time, and now rustup is perhaps more pervasive than it was.

Rustup is definitely in the official runner images: https://github.com/search?q=repo%3Aactions%2Frunner-images%20rustup&type=code even though it is not documented in their README today.

Perhaps getting rustup documented more visibly by Github would be a good route forward?

[djc]

@jcbhmr as an experienced Rust maintainer, just wanted to say that I'm seeing all the repositories I'm participating in migrate to dtolnay/rust-toolchain.

[rami3l]

just wanted to say that I'm seeing all the repositories I'm participating in migrate to dtolnay/rust-toolchain

@djc Yup, I'm using @dtolnay's workflow as well since I know it's becoming the "de facto" option.

However, I do wonder where my knowledge of this comes from, since something is clearly missing, otherwise @jcbhmr should also know about it... Or it needs some more promotion in a certain way?

[jcbhmr]

@djc @rami3l The action it you're referring to: https://github.com/dtolnay/rust-toolchain doesn't seem to appear in my naive search for "setup rust" https://github.com/marketplace?type=actions&query=setup+rust+ or even https://www.google.com/search?q=setup+rust+github+actions

as you mentioned it becoming the "de facto": a beginner like me has no idea what the de facto is because its not really listed anywhere...

when you search https://www.google.com/search?q=rust+github+actions you get @actions-rs, not the https://github.com/dtolnay/rust-toolchain. imo the best-case scenario here is one of:

• an official @rust-lang action to solidify it as THE best choice (you could even transfer/import from said community de-facto one idk)
• somehow reviving @actions-rs(?) since its top SEO
• an official @actions setup-rust action

👆 all that is from the perspective of a user who is completely oblivious to the complicated people-problems or other management issues with accomplishing any of those tasks

from a more conscientious perspective, you mentioned more promotion: maybe on https://rustup.rs or some other official installation place? this could go a ways to cementing a particular action as the recommended one.

[rami3l]

@jcbhmr Discoverability issues are indeed easier to be identified by newcomers like you, thanks a lot for your detailed feedback!

[jcbhmr]

@dawnofmidnight @rbtcollins you mentioned that rustup is available on github actions runners. this is true! and its awesome! 🙌 ...but take nodejs, another popular tool: its already installed at v18 the latest LTS on all github actions runners. and yet there's still a full https://github.com/actions/setup-node which does MORE THINIGS like configuring magic caching and registry and node-version-file etc. ...but that might be out of scope idk 🤷‍♀️.

even other smaller projects like oras are included in the github runner images https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md#cli-toolsbut still provide things like https://github.com/oras-project/setup-oras to make version pinning configuration etc. easier.

i guess what I'm saying is there's a lot of convention around having official-ish setup actions. deno has one https://github.com/denoland/setup-deno even though its just a curl | sh. node has one https://github.com/actions/setup-node even though its already there. ocaml has one https://github.com/ocaml/setup-ocaml etc etc. and right now there's not a clear obvious one way to do it for rust. you've got the builtin toolchain, but then no caching. you've got @actions-rs but that's unmaintained. you've got various others https://www.google.com/search?q=setup+rust+action+github but there's so many and no top-dog one.

slightly off topic: to provide an example of a community project becoming official https://github.com/denolib/setup-deno became the official deno action https://github.com/denoland/setup-deno! its happened! just pointing that out 🤣

[rami3l]

I need an action to setup Rust as well because sometimes my actions happen in a custom Docker image.

FWIW I found out the thread that led me to dtolnay's workflow: https://github.com/actions-rs/toolchain/issues/221. I'd been happily using @action-rs' one for quite a while until it didn't work anymore.

[rbtcollins]

@rami3l OTOH you could build your custom Docker image to have rustup already installed, as part of giving it parity with github runners, no? (rustup-init --default-toolchain=none).

@jcbhmr I use https://github.com/marketplace/actions/rust-cache with many projects, because the caching glue is very nice and hard to replicate.

I think the actions-rs org showed that there are many interesting actions (and more outside that org too - see the awesome-list present in the org).

The salient questions are:

• should rust-lang host one, or more than one, actions?
• if yes, should the rustup repository be the home for said actions

I don't have a strong view on the first one - on the one hand I'm skeptical of centralising things just-because, but on the other hand discoverability is indeed a challenge sometimes.

On the second one though, there is a very clear answer: 'no'. Github requires dedicated repositories for actions published to their marketplace.

So, this bug cannot be fixed here, ever. Making a new repository and all of that is also out of scope for the rustup bug tracker. I haven't ever gone through doing that so I can't even advise effectively!

I suggest reaching out to the infra team and discuss with them, if you decide to drive such a project.

I'm ok with leaving this bug open a little while as a place for you-all to coordinate, but longer term it needs to be transferred to a more appropriate repo, or closed.

[Xuanwo]

I'm not sure why we need a setup-rust action when rustup is already installed and up to date. A rust-toolchain.toml file should suffice for most scenarios. For more complex situations, users can simply run rustup toolchain add nightly.

Perhaps users are seeking a more powerful feature that allows them to enable caching with a simple cache: true?

---

you mentioned that rustup is available on github actions runners. this is true! and its awesome! 🙌 ...but take nodejs, another popular tool: its already installed at v18 the latest LTS on all github actions runners. and yet there's still a full https://github.com/actions/setup-node which does MORE THINIGS like configuring magic caching and registry and node-version-file etc. ...but that might be out of scope idk 🤷‍♀️.

The difference is github action runner install rustup instead of just rustc 1.74. And we have rust-toolchain.toml that can pick correct toolchain to run.

[jcbhmr]

To be more specific about what's missing from "just use rustup its already there":

• caching rust toolchain installations to $RUNNER_TOOL_CACHE
• caching built rust dependencies/artifacts based on Cargo.lock

👆 those are the problems that a rust-lang/setup-rust should solve 😉

along with a bunch of other multi-line command features being collapsed into a single YAML with: config object:

• use rust-toolchain file or ignore it?
• whether to fetch and use latest version or not
• use specific custom version of rust toolchain/rustc/etc.
• install specific targets in addition
• change path to Cargo.lock used for cache
• configure default Cargo registry url
• probably more im missing 🤷‍♀️

[antoyo]

Annotations is another big feature that a rust action could provide.

[Veetaha]

Hey, I found this issue thanks to Reddit.

I suggested there to consider moving actions-rust-lang/setup-rust-toolchain under the official rust-lang org, so that it could get more attention. I wonder what @jonasbb (supposedly the author of this awesome action) thinks about it.

At the very least docs that people go to when installing rust could promote this action.

[rami3l]

FWIW @Manishearth is considering the option of creating a separate team for maintaining official GitHub Actions: https://rust-lang.zulipchat.com/#narrow/stream/301329-t-devtools/topic/Having.20a.20CI.20subteam.3F

We could definitely use some help in this respect, so feel free to chime in if you're interested!

[mariusgreuel]

I don't think this is necessary because, as visible in the rust-lang/rust-analyzer repository, rustup seems to be installed by default on the github actions runners

I think it is still worthwhile having a setup-rust action. The primary reason is that on GHES you cannot assume that your runner has rustup installed. It would be nice to have a way to setup rust on a self-hosted runner similar to what setup-python does. That is, download & install Python if it is not installed yet, setup the proper environment variables, etc. The nice thing about setup-python is that you can put a github.com on a GHES repo and the workflows typically runs out of the box.

Plus, I find it a lot more consistent and trustworthy to have an official action called actions/setup-rust instead of some action on some unknown user account.

[soerenkoehler]

I'm not sure why we need a setup-rust action when rustup is already installed and up to date. A rust-toolchain.toml file should suffice for most scenarios. For more complex situations, users can simply run rustup toolchain add nightly. ... The difference is github action runner install rustup instead of just rustc 1.74. And we have rust-toolchain.toml that can pick correct toolchain to run.

Well, please document this officially on the rust-lang website. I checked there and found no mention of any CI provider setup guide. As others in this thread, I searched the marketplace and got a lot of results which, as a beginner, I cannot judge to be trustworthy or not. And yes, I discovered by chance, that cargo obviously is preinstalled on the Github runner.

Security consideration: As Rust targets to be a safe language, it should also be safe to setup in CI environments. See, the most important threat for any language today are build chain attacks. 🤔 Rust's safety features become irrelevant, if I pick a backdoored Github Action. 🤷

[AlanHale25]

I'm not sure why we need a setup-rust action when rustup is already installed and up to date. A rust-toolchain.toml file should suffice for most scenarios. For more complex situations, users can simply run rustup toolchain add nightly. ... The difference is github action runner install rustup instead of just rustc 1.74. And we have rust-toolchain.toml that can pick correct toolchain to run.

Well, please document this officially on the rust-lang website. I checked there and found no mention of any CI provider setup guide. As others in this thread, I searched the marketplace and got a lot of results which, as a beginner, I cannot judge to be trustworthy or not. And yes, I discovered by chance, that cargo obviously is preinstalled on the Github runner.

Security consideration: As Rust targets to be a safe language, it should also be safe to setup in CI environments. See, the most important threat for any language today are build chain attacks. 🤔 Rust's safety features become irrelevant, if I pick a backdoored Github Action. 🤷

I second this point. At our company, we do not use the provided github runners and we configure ours for added security. At the moment there is no simple way to setup rust in our runners and there is absolutely zero way we would be allowed to use an unofficial setup action. The more small barriers there are to using rust within enterprise sized companies, the slower rust adoption would be and the slower we get maturity in the ecosystem.

Picking a good setup-rust action to make official is such a small ask in exchange for faster adoption and signals that rust is a mature language.

Making one of those actions the official setup-action would also let the community focus on improving it and supporting its development. This should be a no-brainer.

[Xuanwo]

Hi everyone, this issue has been under discussion for nearly two years, and it seems we've reached a consensus that having an official setup-rust action would be beneficial. At the very least, users who don’t want this action can simply ignore it and continue relying on the pre-installed rustup on hosted runners. I don’t see any conflicts or harm here.

Perhaps it's time for us to move forward and take action. Maybe we can set up the repository first so we can get started. Does anyone here know who should be responsible for this?

I'm open to using either rust-lang/setup-rust or actions/setup-rust. However, actions/setup-rust might be the better choice since most individuals and organizations have already permitted the use of actions/* in their CI setups.

also CC @Link- from the github actions team, would you be interested in helping set up such a repository?

[Kobzol]

I think that if we ever decided to host an officially blessed GHA action, it should live under the rust-lang org, not the actions org. Things living under actions don't get automagically maintained, for example the setup-ruby workflow was deprecated and it then moved under https://github.com/ruby/setup-ruby. This also shows that just saying that something is official doesn't cause it to be supported forever :)

[AlanHale25]

I think that if we ever decided to host an officially blessed GHA action, it should live under the rust-lang org, not the actions org. Things living under actions don't get automagically maintained, for example the setup-ruby workflow was deprecated and it then moved under https://github.com/ruby/setup-ruby. This also shows that just saying that something is official doesn't cause it to be supported forever :)

For our particular company, we don't have actions/* allowed, so the review process for introducing the a setup-rust would be the same whether for actions/setup-rust or rust-lang/setup-rust. But again, we would never get permission to use some-good-guy/setup-rust.

[Xuanwo]

I think that if we ever decided to host an officially blessed GHA action, it should live under the rust-lang org, not the actions org.

I'm open to this.

Can we set up the repository first? We can continue the discussion about detailed technical decisions regarding the actions there.

[Link-]

I'm open to using either rust-lang/setup-rust or actions/setup-rust. However, actions/setup-rust might be the better choice since most individuals and organizations have already permitted the use of actions/* in their CI setups.

also CC @Link- from the github actions team, would you be interested in helping set up such a repository?

This is awesome to see!

My advice would be to adopt the approach the Ruby community took and host it under rust-lang: https://github.com/ruby/setup-ruby

I don't believe my group has the bandwidth to take ownership & maintenance of another action.

cc: @lkfortuna

[Xuanwo]

My advice would be to adopt the approach the Ruby community took and host it under rust-lang: https://github.com/ruby/setup-ruby

I don't believe my group has the bandwidth to take ownership & maintenance of another action.

Thank you @Link- for your advice and for providing more context. It's clear that rust-lang/setup-rust is the way to go.

Can we propose this idea at the next rust infra meeting? (I'm not sure about the next steps)

[Kobzol]

Sure, I can bring this up again, but I'm not sure if anything has changed since last time?

IIRC our last stance was that yes, it might have some advantages to have an officially blessed action, but we don't have the maintenance bandwidth to maintain it, and there are other solutions that are good enough for the time being (use a third-party action, or, if that is not allowed, just use ristup directly, which is trivial, albeit it lacks CI optimizations).

And even if we decided that we want to try to bear the maintenance burden, we'd need to figure out the way forward (which is not just creating a repo). Such as what should be the scope of the action? Should it ever only setup rustup and set CARGO_INCREMENTAL=0 and that's it? Or should it handle more complex use-cases? Should it handle rustup missing? What about caching? There is a very popular rust-cache action. Should we copy-paste it? Integrate it into the official action? Should it be two actions or one? Should we even handle caching? Etc. etc.

This kind of project can suffer from scope creep very easily. I think that we could keep the crate maintained if we decided to only support the most basic functionality, but that might in turn result in many repos using third-party actions anyway if they want to get better performance or more featurs.

[spenserblack]

Just as a random user who has used other setup-* actions (Go, Node.js, Ruby), here are some of the features that I'd expect any setup action to eventually have:

• Caching, with the action having a reasonable default for the cache key
• Allow pointing to a version file (.rust-version)
  • For Rust, I think it would be awesome if it could also read the rust-version value from Cargo.toml
• By default, not triggering a download if a version matching the requirements already exists on the system, but...
  • Optionally checking for the latest version. For example, 1.80.0 and 1.80.1 can both meet the requirement to install 1.80. Some users are happy to use whatever may already be on the system, while others always want to use the latest version within their version constraint.
• Outputs for the actual installed version and if the cache was hit.

---

Rustup is an interesting case :thinking: I'm wondering if it would be reasonable to have a separate "setup rustup" action for users who want to install only rustup to their runner. Because multiple actions can exist in a repository, I believe that could be implemented like a monorepo, where the two actions could share common libraries, with usage similar to rust-lang/setup-rust@v1 and rust-lang/setup-rust/rustup@v1.

Also, regarding implementation: I'm sure you already know this (or would discover this soon), but please don't write it as a Docker action, since AFAIK those cannot be used on GitHub's hosted Windows runners.

[Kobzol]

Well, based on what you just described I would probably vote against maintaining it, because we most likely don't have the bandwidth to maintain such a complicated action. That's kind of what I was alluding to before, I suspect that if we released an official action, people would (expectedly) want everything from it. We are already stretched quite thin and adding another publicly facing project that likely requires a lot of maintenance (knowing GitHub Actions) doesn't seem like a good idea.

[AlanHale25]

Well, based on what you just described I would probably vote against maintaining it, because we most likely don't have the bandwidth to maintain such a complicated action. That's kind of what I was alluding to before, I suspect that if we released an official action, people would (expectedly) want everything from it. We are already stretched quite thin and adding another publicly facing project that likely requires a lot of maintenance (knowing GitHub Actions) doesn't seem like a good idea.

I can only imagine the stress and strain the team of maintainers are going through for a globally used tool and language like rust. I think the point the above user was making is that they eventually would like to see a setup-rust tool have all the bells and whistle that the other other setup-* have, but this doesn't have to be now or even in a few years if the team doesn't have the bandwidth. But even a minimal setup-rust action with the official rust slap on it would go quite far in helping with adoption. Even approaching the maintainer of this action to bring it under the rust-lang flag could be a good way to go.

[spenserblack]

Well, based on what you just described I would probably vote against maintaining it, because we most likely don't have the bandwidth to maintain such a complicated action.

Oh, yeah, I hope it didn't come off as a list of demands. I was anticipating the types of feature requests that would probably come in, based on how other setup-* actions ended up. Totally understandable that it would be too demanding -- an action can take a lot to maintain. At a quick glance at Ruby and the setup-ruby contribution stats, it looks they chose one member to be the action maintainer, who isn't under much pressure to maintain other Ruby repositories. Though I'd take my quick scanning of the org with a grain of salt.

Honestly, an "unofficial official" action, a community-maintained action that the Rust project can recommend as a good and trusted option, would go a long way towards helping users confidently set up their workflows IMO. Just something documented somewhere so that Rust programmers can get pointed in the right direction.

[soerenkoehler]

I second the statement of @spenserblack :

Honestly, an "unofficial official" action, a community-maintained action that the Rust project can recommend as a good and trusted option, would go a long way towards helping users confidently set up their workflows IMO. Just something documented somewhere so that Rust programmers can get pointed in the right direction.

No need for rust-lang-maintained solution, but some rust-lang-endorsed action for a start. (Then once in the future, there could even be a set of 3rd party libraries and tools which get an offial badge "approved by rust-lang.org" to avoid debacles like the one of .net Moq some month ago.)

[Kobzol]

The problem with that is that "unofficial official" is really not much different than "unofficial". The only reason why an official action should exist is that it will be maintained and safekeeped by the Rust Project, which will enable parties that trust the Project to also trust that action. That is IMO really the only reason; it's not like the Rust infra team has some secret superpowers that would enable it to produce better code or more features than third-party actions (in fact it's likely the opposite, given all the other projects that we maintain).

Endorsing a third-party action would in fact be even worse than the status quo, because people would assume that the action is trustworthy and kept secure by the Project, while in fact that would not necessarily be true, because the Project could not make sure of that. We would essentially say "use X, we promise that it's secure", without ensuring that it is in fact secure. Not to mention that we would have to pick favourites within the ecosystem, which is something that we actively try to avoid. And once the endorsed action would become unmaintained, people would have to switch to a different solution anyway.

Anyway, I'll bring this topic up in our next meeting again. If there will be interest from the team (which is uncertain), I could write a document that would enumerate all the possibilities here and their trade-offs, so that we have a more complete picture for the discussion.