Show HN: Hm – a task runner with a Python DSL, growing into a CI/CD system

12 points

a month ago

Hi HN! My name is Marko and I am working on a CI/CD system at harmont.dev, a CI/CD system that sucks slightly less. As I've been working on the cloud, I realized that the CLI might be generally useful as a task runner, even if you don't care for our CI/CD, and that's what I'm sharing here!

Every CI system I've used at Tesla, Bun, and mesa.dev has had the same problems: stateless and slow (GHA), or stateful and horizontally unscalable (Jenkins), with YAML on top of either. The straw that broke the camel's back for me was the realization that all my Claudes are waiting upwards of an hour. So I quit my job to work on harmont, which aims to solve all of these pain points I've had.

In its current state, the project is very similar to Dagger in spirit with the core difference of harmont having what I believe to be a more pleasant API as well as being smaller in scope.

I'm looking for opinions and feedback. What might be the most interesting with the CLI is the DSL -- I've tried to make it ergonomic and friendly. To get started:

  curl -fsSL https://get.harmont.dev/install.sh | sh
  
  mkdir foo
  cd foo
  uv init
  cat >> pyproject.toml <<EOF
  [dependency-groups]
  dev = [
    "pytest",
    "ruff",
    "ty",
  ]
  EOF
  
  # Create the pipeline
  mkdir .harmont
  cat > .harmont/pipeline.py <<EOF
  import harmont as hm
  from harmont.python import PythonToolchain
  
  @hm.target()
  def project() -> PythonToolchain:
      return hm.python(path=".")
  
  @hm.pipeline(
      "ci",
      default_image="ubuntu:24.04",
      triggers=[hm.push(branch="main")],
  )
  def ci(project: hm.Target[PythonToolchain]) -> tuple[hm.Step, ...]:
      return (
          project.test(),
          project.lint(),
          project.fmt(),
          project.typecheck(),
      )
  EOF
  
  hm run

Currently our API has pretty good support for Rust, Typescript and Python. There are other languages that are "supported" in the examples, but those are mostly demo APIs and are likely to change, aggressively. The project is early, but usable and I'd love to get your feedback.

What's coming next:

  - COW filesystems: In a future release of hm, we mount FS layers on top of preceding layers, copy-on-write. I ran some experiments and they resulted in up to 40% faster runs on `uv run ruff`-style commands.
  - Development containers: `hm dev` enables you to spin up your application in however many instances you need -- if you have a local application, there is nothing stopping you from spinning it up once, twice, or 10 times.
  - The cloud: In parallel to the CLI, I've been working on the cloud, which I am hoping to private-access release in the coming month. It follows the same model as the CLI, but uses a very different execution engine (supporting RAM caches too, for you Bazel enjoyers =).
  - Additional language SDKs -- The private-access cloud is written in Haskell, Elixir and Rust. We already have harmont rules for Rust (which I would suggest you check out in Harmont's very own dogfood pipeline: https://github.com/harmont-dev/harmont-cli/blob/main/.harmont/ci.py), but we're adding more languages!
  - Plugin system: I recognize that not everyone will want to join the Harmont cloud but may find some utility in the Harmont task runner. At some point, I had a plugin system in place that allowed you to download and use harmont without any cloud-specific bloat, but unfortunately I tore that out, because the code wasn't great. Definitely working on bringing that back.

Full disclaimer: I am the founder of Harmont, Inc. PBC. We are committed to the CLI remaining open-source and as bloat-free as possible and doing the best we can with the cloud for the community.

PS: I've gotten questions about the name. It is a reference to https://en.wikipedia.org/wiki/Roadside_Picnic (awesome sci-fi book, worth a read =) )

curl -fsSL https://get.harmont.dev/install.sh | sh mkdir foo cd foo uv init cat >> pyproject.toml <<EOF [dependency-groups] dev = [ "pytest", "ruff", "ty", ] EOF # Create the pipeline mkdir .harmont cat > .harmont/pipeline.py <<EOF import harmont as hm from harmont.python import PythonToolchain @hm.target() def project() -> PythonToolchain: return hm.python(path=".") @hm.pipeline( "ci", default_image="ubuntu:24.04", triggers=[hm.push(branch="main")], ) def ci(project: hm.Target[PythonToolchain]) -> tuple[hm.Step, ...]: return ( project.test(), project.lint(), project.fmt(), project.typecheck(), ) EOF hm run

- COW filesystems: In a future release of hm, we mount FS layers on top of preceding layers, copy-on-write. I ran some experiments and they resulted in up to 40% faster runs on `uv run ruff`-style commands. - Development containers: `hm dev` enables you to spin up your application in however many instances you need -- if you have a local application, there is nothing stopping you from spinning it up once, twice, or 10 times. - The cloud: In parallel to the CLI, I've been working on the cloud, which I am hoping to private-access release in the coming month. It follows the same model as the CLI, but uses a very different execution engine (supporting RAM caches too, for you Bazel enjoyers =). - Additional language SDKs -- The private-access cloud is written in Haskell, Elixir and Rust. We already have harmont rules for Rust (which I would suggest you check out in Harmont's very own dogfood pipeline: https://github.com/harmont-dev/harmont-cli/blob/main/.harmont/ci.py), but we're adding more languages! - Plugin system: I recognize that not everyone will want to join the Harmont cloud but may find some utility in the Harmont task runner. At some point, I had a plugin system in place that allowed you to download and use harmont without any cloud-specific bloat, but unfortunately I tore that out, because the code wasn't great. Definitely working on bringing that back.

1 comment

1 comment