Hybrid Rust (outside) + Bash (inside)

[schneems]

This PR removes all Bash logic outside of the container and replaces it with Rust commands, see the README for more info. It removes all Ruby dependencies.

• Ruby binary building: Refactored with one minor change that allows Ruby 3.3 to compile on Ubuntu 24.04 (ARM architecture). https://redmine.ruby-lang.org/issues/20506#change-108445
• JRuby binary building: All new functionality. The old repo https://github.com/heroku/docker-heroku-jruby-builder is now deprecated.

Superscedes #46

[colincasey]

I see no issues with this approach. It's nice to see the Ruby code eliminated and the amount of Bash scripting minimized. Mind you, I don't routinely have to do binary builds so maybe I'm not the person who should validate if the tradeoff between the Rust code vs. plain Bash scripting is worth it.

That said, what kind of approval are you looking for here @schneems?

[schneems]

what kind of approval are you looking for here

The approving kind 😅.

Short: Compliance check.

Long: Honestly, "doesn't look actively malicious" is good enough. A rough scan for any "uh, this is clearly wrong logic" perhaps. Also worth noting, that I need the Heroku-24 ARM builds fix that's in here.

🙇🏻 This is frankly the kind of project that can be rewritten in a (long) weekend, so I'm not too worried about architecture mistakes or perfect code. If anything, I think I went TOO far with Rust (i.e., error handling, etc. instead of expect), but that's fine.

If we have better patterns in the future I can adopt them. I'm open to ideas. For example: I chose to use different binaries for the different commands (build/check) as I felt not having to share an argument parser made things simpler, but...maybe it doesn't? Hopefully, this is a thing we can keep trying to improve.

[schneems]

We talked offline about:

• Reducing the error handling logic using anyhow or Box<dyn std::error::Error> (goal is less code)
• Exploring using a rust nightly feature that allows inline cargo toml declaraions for scripting

#!/usr/bin/env -S cargo +nightly -Zscript
/// ```cargo
/// [package]
/// edition = "2021"
/// ```
fn main() {
  // script goes here!
}

[schneems]

Turns out this is the correct syntax for being able to download dependencies:

#!/usr/bin/env -S cargo +nightly -Zscript
---
[package]
edition = "2021"

[dependencies]
java-properties = "2.0.0"
glob = "0.3.1"
clap = { version = "4.5.4", features = ["derive"] }
shared = { path = "/Users/rschneeman/Documents/projects/work/docker-heroku-ruby-builder/shared" }
// ...
---

I got it working, but I don't think we should move forward here:

• Currently, the project is listed as not supporting workspaces for v1 from Tracking Issue for cargo-script RFC 3424 rust-lang/cargo#12207 on Jun 26, 2024

That means that cargo test will pass even if bin/ruby_check.rs has a syntax error, which is not a great development experience.

I also had to move away from <dep-name> = { workspace = true } to be able to manage dependencies as shared due to this constraing.

• The syntax or features may change, based on how I thought it should work. That could mean that running rustup update could break this deploy script, and we would have to stop and fix it. We could work around that by pinning to a specific rustup version, similar to how I'm doing it inside of docker, but I wanted to document it as a downside either way.

I'm pushing my code to a branch for reference to possibly share this feedback experience where someone can also view the code https://github.com/heroku/docker-heroku-ruby-builder/tree/schneems/riir-rust-script-nightly-experiment-jun-26.

[colincasey]

In general I think this approach of using Rust for external script needs and Bash for internal container needs is a reasonable trade-off.

I'd like to see the Rust parts be more script-ish which, I think, would simplify the project in general, some of those features are not fully baked yet. Using cargo run --bin ... and requiring the full cargo workspace crate layout is less than ideal but it's fine for now.