Agenda Item: UNOfficial Github Actions @actions-rs for Rust Community has been Archived

[elasticdotventures]

👋🏻 .. I'm hoping to discuss to rust-lang/infra to bring focus to a recent happening where the most popular "unofficial" collection of
Github Actions for Rust-Lang @actions-rs https://github.com/actions-rs have all be archived due to the primary maintainer @svartalf
"taking a break to focus on family, stepping back & worried to appoint somebody else for security reasons" 😓

The problem with the unofficial rust ci/cd actions for github going offline is there is today no "official" equivalent.

The @actions-rs while unofficial constituted the most popular & trusted collections of ci/cd actions for Rust on github are now archived & unmaintained. The org was archived without any warning, there is scant detail and it does leave the opportunity open for a host of bad actors to do nefarious things. In my view the worst case is another unofficial version appears and we have to do this dance again in the future.

A full discussion & backstory can be found here:
actions-rs/cargo#59 (comment)
Unfortunately due to the unannounced archival, these discussion have all be shut down.

I checked the rust-lang/infra prior meeting notes and didn't see this topic covered yet. I'm requesting this topic be added to the next meeting agenda.

The rust-lang/infra team is proposed as one of the trusted parties whom could take ownership to create an "official" set of actions for the community. (I realize ya'll are internal tooling, but maybe it could be a dogfooding scenario) ..

Other proposed parties for taking ownership could include the github actions team who maintain the official actions for variety of languages such as actions/setup-node, actions/setup-python, actions/setup-go, actions/setup-java, etc. .. but I suspect that github actions org would prefer Rust-lang/infra or something attached to Rust foundation. I'll try to raise this issue with them as well.

For reference that discussion is here:
rust-lang/rustup#3409

I must say, it's always bothered me that the Rust Community doesn't have an official set of github CI/CD actions under rust-lang/actions. I'm going to also try and bring this issue to the github actions team to hopefully foster a discussion.

I'm not proposing any more than taking the existing actions, merging any sane PR's (there are many), and potentially coordinating with the github/actions team to either take direct control or at least de-list the archived versions, try and reach out to the existing author to update the README's to point people at a new one.

On a personal note, if there is nobody on the rust-lang/infra team who is willing to assume this responsibility on, then in that case I'm also volunteering in whatever capacity is helpful. Thanks!

💖🦀

[elasticdotventures]

Posted on Github Org community discussion General topic

[elasticdotventures]

I've also written @svartalf of @actions-rs a personal appeal email asking him to consider adding the rust-lang/infra-team @pietroalbini, @jdno, @Mark-Simulacrum members to his org. 😉 Hope that's okay!

[Kobzol]

Having an official set of CI actions would be great, although it should be noted that there's not only Github Actions, there are more CI systems, and it's probably not within our capacity to maintain actions for all of them. In fact, it might not be in our current capacity at the moment to maintain any of them.. :)

I agree that having some notion of an "official" GHA setup could be helpful, especially to new Rust developers, I'm not sure if it's a magical bullet to just put such an action into the actions (or, for that matter, rust-lang) GitHub organizations. I examined the various setup-* repositories within the actions organization, and it seems that at least three of them are no longer maintained (https://github.com/actions?q=setup&type=all&language=&sort=), namely Ruby, Elixir and Haskell.

I wonder what's the target goal that you're aiming for. Do you find something wrong with the existing solutions, e.g. https://github.com/dtolnay/rust-toolchain? Or do you simply want them to live under the rust-lang organization? Or do you want the Rust Project to officially bless a specific project?

Note that the Rust Project currently doesn't have an official set of blessed crates/projects/actions, and even if some action would be moved under the rust-lang organization, that wouldn't really change anything. There are many unmaintained or very low maintained projects that are under that organization currently.

One thing that might be worth improving is the marketplace prioritization, as you have said. I tried to search for rust on the actions marketplace (https://github.com/marketplace?category=&type=actions&verification=&query=rust), and the first results aren't great. rust-toolchain and rust-cargo are both quite low in the resulting list. I'll try to schedule this topic for our discussions with GitHub.

[elasticdotventures]

@Kobzol --
The short answer is "yes, an official blessed version" so the community can coalesce on a set of best practices, & reduce our collective tedium.

I have zero issues with @dtolnay (👍🏻), and I'd suggest/vote/elect him as a maintainer under rust-lang org repo.
My concern is for them, or others that will come after them -- because maintaining a ci action isn't likely to generate sufficient sponsorships to sustain an individual or group of individuals, BUT supporting the action, being patient with the neophytes-rustaceans publishing their first package .. -- THAT level of patience & care is likely to require a bit of effort and that will probably ultimately burn maintainers out (ex: @svartalf), and that means we (the rust community) will be doing this needless migration dance every few years. We needed a hero, @dtolnay stepped up (for now) .. and they are already a member of rust-lang, so this should be straightforward.

This is why I'm saying having an official action is appropriate for rust-lang, because Rust Foundation is a registered non-profit that could potentially hand out stipends for maintaining projects like this .. I'm saying that I don't expect @dtolnay to setup & operate their own charity, that's a ton of paperwork! It makes more sense to invite them (and/or others who might be interested) to maintain the rust-lang version and they can use that to apply for a sponsorship grant if/when he/she/they and/or other future contributors to the rust ci/cd tooling require some form of sponsorship/financial remuneration, which is probably inevitable giving that rs-actions was used by 150,000+ projects. Also a huge portion of the users aren't necessarily ci experts, and they don't want to become ci-experts, they want to publish and get back to working on their mvp.

This is why having the gh actions under Rust Project WOULD ABSOLUTELY change things, firstly - it provides a trust signal & gravitas, it says this isn't maintained by one person, the gh actions should be a community project contributions are welcome - and oh btw, that community comes with behavior, contribution and ettiquete guidelines too (yay!).

I found myself today looking at https://github.com/awslabs/mountpoint-s3/tree/main/mountpoint-s3-client .. of course, it uses rs-actions, 🤦 .. there's 150,000+ projects that are using rs-actions that will need to shift to something else over the next decade, that's a lot of wasted productivity/research, it'd be nice to just need to that now while it's only 150,000 instead of next time when it'll be 10x that. .. rust-lang official, put out an announcement, everybody moves over git it to #1 on marketplace.

Yes - there are many other ci pipelines besides github, .. but gh actions is the 900lb gorilla. Do you recall Crates.io could only run on github for many early years. I think many other pipelines are starting to adopt or provide conversion scripts for gh actions.yaml format. If somebody is attempting to maintain or innovate in the ci pipeline space -- they would already have a crystal clear motivation to try and leverage the existing gh-actions ecosystem because it is an open "standard" that is easily embraced & extended. Any tool that doesn't have a plan for gh actions probably won't gain a large enough market share to even warrant a foot-note.

[Kobzol]

Well, we don't really bless anything or make favorites at the moment, and we're not even clear on what does it mean for a crate to live under the rust-lang org (we're currently trying to start a process to define what does it mean for the project and for the original owner).

I guess that we could ask someone to move their actions repo under rust-lang, but I'm not sure of the benefits of that at the moment. You could then perceive it as official, but what does that even mean? If rust-toolchain is moved under rust-lang, and e.g. dtolnay stops maintaining it, there's no magical power that will generate new maintainers just because the project is under rust-lang. It could end up being unmaintained all the same. Pretty much the only benefit of moving the repo under rust-lang at the moment is to increase its bus factor. But it's unclear to me if actions-rs would be further maintained (instead of being replaced by other projects) if it would have been under rust-lang. Note that the other repos also use different approaches, as everything evolves.

As long as the repo is accepting open-source contributions (which I assume rust-toolchain does), it can thrive both under rust-lang, but also outside of it, as long as some new contributors step up. Regarding stipends, we're currently trying to define some projects that could be up for sponsorship, but again, that's not relevant to under which organization the project lives.

[elasticdotventures]

@Kobzol
fwiw: My expectations for rust-lang are extremely low in terms of resourcing. I'm aware at times it could be compared to a circus (**having at least a few clowns 🤪).

The expectation is that rust-lang is for better or worse it is the organization that should (attempt) to best represent the interests of the entire community. An organization consisting of more than a single individual, and that organizational construct as Rust Foundation is simply more durable than any single individual, having a director, a board, and probably some employees & volunteers.

I'm mostly concerned with what in Australia we call the "Tram Factor" in the US it's the "bus factor" which is to say that I expect if this or similar situation arose (again) that rust-lang as an organization could survive and can in the wake of a devestating loss reorganize and provide a modicum of continuity + succession planning if/when the need arose to designate a steward for any piece of critical infra. Given that no individual contributor (**except possibly future LLM's / robotic overlords) are actually immortal succession planning is something we must think about. The expectation of rust-lang is to be able to ensure succession if/when such a need arises.

I was working on the new spiffy AWS S3 mountpoint this week (built in their rust SDK, I'm happy to see AWS offering Rust) and of course it's still using rs-actions and !@#$ .. yeah, so there's like 150,000 repos that all need an update. In terms of person-hours this is a at least 5 minutes to create+review, it's like 12,500 lost hours of Rust productivity! In 5-10 years it'll be 10x that number if we need to do this again.

I totally respect that as a nascent org the Rust Foundation is still getting organized. I proffer this is definitely in it's role.

This rs-action is a great example - anything that is expected to become a single sourth of truth, which we anticipate is or will be used a very wide audience of the community .. ex: 150,000 repos then the rust-lang has what I would term as responsibility to provide continuity & ensure capability of succession, if/when that should be forked and put under a hosted mechanism where the org can intervene if the maintainer is absent, dead, indisposed blabla. That succession capability is a big trust signal of maturity to businesses considering using Rust, and that is why having a rust-lang & Rust Foundation bring gravitas.

I'm not proposing that @dtolnay stop being a maintainer (he's already a significant contributor to rust core) -- I'm asking if anybody beyond me recognizes this is a good moment to acknowledge the importance & underpinnings of this piece of tooling. Can we acknowledge that Github CI actions are an indispensable & ubiquitous step for every single rustacean, every new project, every first time contributor -- I was feeling like we (the present day community) have an obligation to future rustacean generations to light a beacon of trust under rust-lang for CI actions. I expect someday that cargo will have a super convenient generate ci feature like wasm-pack does, that's a lot more likely if we have the actions hosted under rust-lang.

I'm hoping @dtolnay will see this and agree. The unexpected archival was annoying, after it happened - I'm glad @dtolnay stepped up "in the moment", but I'm not sure if he will want to carry the rs-actions mantle for the rest of his career & wants to do this forever. Please remember - if he ever decides to transfer the repo, the github marketplace stars won't transfer with the repo (causing this confusion yet again, everybody will still need to update yet again), so it makes sense to ask @dtolnay to transfer & start building on a "forever" base which should either be a github/setup-rust or rust-lang/github-actions or something obvious. Under the lindy principle, we can have an official version if we agree to call it official.

My real goal/hope of this message was that @svartalf would see it, then unarchive & transfer the original rs-actions to rust-lang, but now I think it's up to @dtolnay to decide.

[Kobzol]

I agree that increasing the bus factor is one of the biggest motivations for moving projects under rust-lang.

There are many projects using actions-rs. They will continue using it, regardless of the org that owns it, until they will be forced to switch to some other action for some reason.
If I understand it correctly, you are suggesting that actions-rs is moved under rust-lang, so that its development can continue, without the other projects having to eventually switch to something else? (do the original action references in YAML workflow files keep working if it's moved to a different org?)

[jcbhmr]

Remember the branding argument too! Having something under @rust-lang or another "blessed" place makes it much more likely to get highlighted in official documentation, references, guides, cargo new, etc. so that new users are not misguided and confused when they search for setup rust github actions as to which one is the right one.

In the same vein of "branding wins", Deno moved the @denolib setup-deno repository to the official @denoland organization and it is now the go-to Deno configurator action. That strengthened the "getting started" guide with regards to CI. https://docs.deno.com/runtime/manual/advanced/continuous_integration 👈 Having an official action or another "blessed" action to point to makes writing documentation for beginners more straightforward. There's no "choose from one of these 5 options that may or may not exist when you read this" decision paralysis; it's just the one blessed/official action.

[briansmith]

I used actions-rs for years and when it got archived I just stopped using it. rustup is preinstalled and that gets most of the bootstrapping we need for other things. I think effort is better spent improving rustup and related tooling in a way that's CI-environment-independent. FWIW, my two changes to remove my action-rs dependency were:

• briansmith/ring@b349cec
• briansmith/ring@6bd1a21

[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
• add annotations for warnings and errors

👆 those are the problems that a rust-lang/setup-rust could 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 🤷‍♀️

-- from rust-lang/rustup#3409 (comment)