Show HN: Hammerkit – Build Tool(github.com)
github.com
Show HN: Hammerkit – Build Tool
https://github.com/no0dles/hammerkit
15 コメント
Thank you very much for your feedback :). I did take a look at both (make and bazel) before I decided to start this project.
What I was missing in make was the containerization which enables running tasks inside container and take leverage of the installed tools there. That keeps the requirements on available tooling low and makes it als easier for cross platform development.
Bazel on the other side was very hard to get into and felt really complex. I am sure it's a great build tool and you can archive great things, but I thought maybe I could create something simpler that's almost as relable without the complexity. I am sure I miss a lot of features in my project that bazel covers and hope I do not end up with the same complexity.
At least I will learn a lot, either way :)
What I was missing in make was the containerization which enables running tasks inside container and take leverage of the installed tools there. That keeps the requirements on available tooling low and makes it als easier for cross platform development.
Bazel on the other side was very hard to get into and felt really complex. I am sure it's a great build tool and you can archive great things, but I thought maybe I could create something simpler that's almost as relable without the complexity. I am sure I miss a lot of features in my project that bazel covers and hope I do not end up with the same complexity.
At least I will learn a lot, either way :)
One of the most common things that developers generally build is a build tool. I really believe building CI/CD tool, build tool is gateway to devtool space.
Having said that I truly believe build tool, CI/CD space is overcrowded, very competitive and the competing solutions are not so much differentiates, may be 10% better. I don't want to discourage you because there are lot of inherent learning while building build too.
You probably want to think how you completely revolutionize the build tool space.
Having said that I truly believe build tool, CI/CD space is overcrowded, very competitive and the competing solutions are not so much differentiates, may be 10% better. I don't want to discourage you because there are lot of inherent learning while building build too.
You probably want to think how you completely revolutionize the build tool space.
While we are at it. Does anybody have tips what is the best solution to ensure I get proper upgrades to my artifacts?
Something like renovatebot or using OBS? What do you use? It feels like people I know are mistaking Docker as a dependency manager. But the fundamental problem must have been solved already at least by Linux distributions. I wonder how other people adopt this for their private repositories?
This looks very similar to https://taskfile.dev (Go, 3.5k stars).
Thats very true, I used taskfile personally and professionally for a few projects and encoutered some problems I tried to solve with this project. I even tried to contribute there, but it was not that easy, since I am not that fluent in go
I'm curious: what kind of problems?
maybe problems is the wrong term, lets call it features I was missing.
- without docker images in tasks tooling was not always the same on different machines
- a docker image that can be used for gitlab ci
- caching on CI systems was a huge effort, requiring to specify all .task directories and build directories
- limited includes of other build files, no nesting or loops, making project style taskfiles not possible
- the cwd of includes is not relative to the reference taskfile
- detect changes in cwd during commands, for example with `cd ..`
- a service definition, allowing to use databases with some healthchecks to detect startup delays
- limiting cpu/memory of build steps / limiting tasks that are executed parallel by resource availableLooks nice. As someone unfamiliar with Make, can someone explain why YAML is a bad idea for something like this?
My favorite part (unironically) is how this is written in TypeScript. Easier for me to contribute features and fixes.
My favorite part (unironically) is how this is written in TypeScript. Easier for me to contribute features and fixes.
You can create a DAG in yaml it's just that 99% of projects ignore creating a graph and just treat 'build rules' as an imperative script. The other problem with YAML-as-a-lang is eventually you need to express something that isn't just static key vals (see ansible) and turns into a quite a mess.
Btw, you should add a JSON schema for the build.yaml data, so VSCode can provide auto completion.
https://brunopaz.dev/blog/how-to-create-your-own-auto-comple...
https://brunopaz.dev/blog/how-to-create-your-own-auto-comple...
Awesome, will do! Did use JSON schema before, but didn't know it can be used for yaml as well.
Makefile?
When you do finally outgrow Make you should be looking at Bazel or similarly full build system.
Creating Make with YAML syntax is strictly worse than Make and yet this has to be the most popular style of "new build systems" I am seeing recently and it really does confuse the shit out of me.
EDIT: Realized this is Show HN so here is some constructive critisism. If this is a learning exercise on how to build graph style build execution systems then carry on. If however you think this is needed I think you should invest some time learning from Bazel and other new generation build systems. Ideally take some large multi-project builds and try converting them between this tool and Bazel and see if you can understand what is different paying close attention to cachability, parallelism and repeatability. That last one, repeatability is actually what makes Bazel stand out from most of it's competitors so it's worth understanding why it values it so highly when it clearly has a very high cost.