vito

Happy to hear from a Concourser! The transition to Dagger isn't fully defined yet, but we're getting there. It's taken a lot of time to find the right primitives and build a solid engine for maximal caching, but we're excited about what we're launching soon. It covers the middle parts of a Concourse pipeline really well (build + test, CI checks) but we still need to solve the beginning/end (monitoring inputs, shipping/releasing).

Will be following this closely! I've been working on something similar called `dagger agent`. The idea is to build on Dagger's sandboxing and (ab)use its existing infrastructure of "reproducible function recipes flowing through OpenTelemetry" - by replaying those recipes from their trace in your local engine or from Dagger Cloud.

The durability has been a lifesaver when I'm dogfooding and the TUI crashes or the session spawns 5 ambitious subagents and OOMs my laptop. Quite a few times I've migrated a session to Cloud's engines and kept going from there. Effectively the entire state of multiple sandboxes is put through storage as humble OTLP data and revitalized on whatever hardware you bring it back on, like thawing Walt Disney (and giving him a stimpack I guess).

My end goal is to have long-running sessions that hold curated context via tool state so it's durable to compaction, and to be able to keep a multi-agent month-long workstream going from my phone by messaging its leader through Cloud. It's been a passion project for over a year and it's taken a lot of world-building along the way (new Dagger core APIs, and Dagger 1.0 being the top priority independent from all this agent stuff). I'm finally at the point where I'm using it productively but I don't have a quick-start yet (edit: here's a quick and dirty one - https://gist.github.com/vito/bed465ed43a09a433b85a360311c7d3...)

Find me in Dagger.io's Discord if you're interested :)

The Bash compatible syntax is just one representation of an underlying cross-language API. You can also write code in your preferred language, provided there's an SDK for it. (Currently: Python, TypeScript, Go, PHP, Java, Elixir, Rust, .NET)

But if you're talking specifically about shell or a "native" REPL in a safer language - I also want to scratch that itch. Some day I'll dust off https://github.com/vito/dash :)

What you aren't including is the chronic cost of maintaining the status quo, which is the entire reason for making the change. Sometimes making no decision costs you more than making a risky one - and if the decision is risky, you'll want to investigate it first.

During that investigation you discover things (like having to implement your own components) and try to account for how much they'll subtract from the time and energy you save. If the calculus works out, you keep going. If it doesn't, you stop. We kept going, and now we can ship complex features and optimizations to both UIs within a day or two.

Here's one of our public traces if you want to try the real thing: https://v3.dagger.cloud/dagger/traces/6898273d59ad62a6df1e9e...

The compiler will tell you if the types aren't compatible, and this is only for primitive comparable types. What `min()` implementation could you have that even does something different?

Yeah that's a good point. There are definite trade-offs to going for only one or the other. If there's a nice way to support both without too much maintenance overhead, that'd be my preference. There are a few popular Go libraries which support that, like https://github.com/spf13/viper - which we'll probably consider switching to as part of a general CLI overhaul.

For a long time now we've been primarily focusing on the core design, concepts, and architecture at the expense of documentation and introductory material and outreach - we've never had a dedicated technical writer, so documentation is really best-effort. Now that the dust is settling on our roadmap I feel a lot more confident in increasing our focus on onboarding, operability, and developer/user experience in this coming year. :)

(Concourse co-creator/OSS lead here.)

Our CLI hasn't really aged well and that's something I'd like to address soon - probably going more in the direction of config files instead of flags/env vars. It'd be a lot easier to document with a proper schema. Thanks for the feedback and sorry the experience is still pretty rocky!

All it really proves is HN's tendency to tear down projects for any arbitrary reason they can find.

The Books - Free Translator (https://www.youtube.com/watch?v=jGjs8TCGvQI)

Solitude even has the victory animation: http://i.imgur.com/IlSm5pE.png

Funnily enough if you leave the tab in the background, the events queue up and when you tab back there are a bunch of cards bouncing around at once: http://i.imgur.com/dNObRGb.png

If someone writes a Garden backend for it, sure. Here's an example of a pretty small backend that delegates to `systemd-nspawn`:

https://github.com/vito/garden-systemd

I'm curious to know how your flow through the docs went. We inlined "getting started" into the main page, and had the Setting Up section show "vagrant up" first, and we have warnings above sections that are not critical to know before learning Concourse itself, which then take you right to "Hello World". It's already optimized for "Concourse made easy" - but perhaps our navigation is not?

I should probably add a warning above the BOSH section though, or even the binaries section.

The trouble is, reality is complicated, regardless of whether it's documented or not. I've found that a lot of open source projects simply don't document things to give an illusion of simplicity; people just forget all the manual labor they had to do after downloading that .deb and installing it across 10 machines and maintaining those machines over time. Our docs cover BOSH as our preferred tool for clusters. If you don't want to use BOSH, just use the binaries and your own deployment tool.

We don't build .debs yet; as soon as we do other people will want .yum, and another will want Docker images, so we built the binaries that will feed into those first, which is often what I look for when kicking the tires on something anyway.

Concourse just talks to Garden, it's up to the Garden backend whether or not it actually does containerization. So on Windows it just does the world's worst containerization (cd'ing into a directory), though it at least guarantees that the processes all die.

There's a proper Garden Windows backend in the works which we'll switch to at some point once we better understand it: https://github.com/cloudfoundry/garden-windows

Woops, typo'd in my original comment: it supports Linux, Windows, and OS X. :) Binaries here: http://concourse.ci/downloads.html

You pretty much got it right. That page is still a bit rough; we'll give it some TLC soon.

Workers are just machines running a container management daemon (much like a Docker daemon) and a volume manager (a custom daemon for managing caches and efficient artifact propagation between containers). Not sure how you got to Cloud Foundry though, it's not really related. Garden lives in the Cloud Foundry GitHub organization, as it's also used by Cloud Foundry, but you don't need to know anything about CF to use Concourse.

Concourse supports Linux, Windows, and OS X. You can see an example of this here:

https://ci.concourse.ci/pipelines/main/jobs/fly/builds/2621

There are prebuilt OS X binaries available on the Downloads page. Each binary supports both running the web UI and acting as a worker:

https://concourse.ci/downloads.html

That command would just be `fly` or something else coming from Concourse. To me it makes more sense for the entry into the system to be safeguarded with validation, and then possibly bring your own filesystem-based configuration management system that goes through that same front door, building on trusted tools from Concourse itself. Mucking with files on disk that directly affect a live system (shipping production code!) seems like a recipe for disaster.

We run browser-based tests in our own pipeline (I'm on the Concourse team). We just use `xvfb-run` around our test script. We also build VirtualBox images using a systemd-based Garden backend running on a dedicated server (not a VM).

I find these approaches better than risking test pollution, especially when it comes to building VMs and spinning up desktop apps.

In addition to what XenoPhex said (`fly execute`) you can always just configure a job that's only ever manually triggered.

The nature of Garden is to support container managers as Garden backends. Garden itself is just a client/server API spec.

For example, [Guardian](https://github.com/cloudfoundry-incubator/guardian-release) is in the works to replace the Linux backend with a thinner runC-based backend.

The main value we get from it is having a nice Go API and not having to overhaul everything using Garden every time some shiny new container tech comes out.

Yup (is). You'd just run `concourse web` and then `concourse worker` on the same machine. If all you have is a Mac Mini there's one gotcha, though: currently none of the resources will run on OS X, as they're built as Docker images. So you'll still need at least one Linux worker somewhere.

I think the next step from us may be to start building Vagrant boxes that just spin up a worker, parameterized with credentials to register with a Concourse `web` instance. That way you can run Concourse on OS X for iOS testing/etc. and still have all your resources and Linux containerization when you need it via a tiny local VM.

@vito from the Concourse team here.

We've recently started building standalone binaries which should lower the barrier to entry. Concourse itself has never been too tightly coupled to BOSH, it's just been the quickest feedback loop for us during development, so it ended up being the first thing we documented, primarily for internal use as we haven't really "launched" yet.

Binaries are available for download in the GitHub releases[1]. Check the README.md[2] for details. We'll be launching 1.0 very soon and part of this will include a major docs/website revamp which promotes the binaries to the "main stage". It also switches to BOSH 2.0, which drastically simplifies the deployment configuration necessary, but it still takes a backseat to the lower-upfront-cost distribution formats in the new site.

Glad you liked Concourse otherwise, and hopefully this helps. :)

[1]: https://github.com/concourse/concourse/releases [2]: https://github.com/concourse/bin/blob/master/README.md

Wrote a similar web-based tool a while back, primarily for grouping goroutines by their source location:

https://github.com/vito/swirly

Try it out here:

https://rawgit.com/vito/swirly/master/index.html

...with: https://gist.githubusercontent.com/vito/486918d4c759184eb1d4...

Same issue on Android: http://i.imgur.com/FKPvJsq.png

Time to avoid /newest.

Same on Android, and the same weird second delay. Huh.

Screenshot: http://i.imgur.com/FKPvJsq.png

Feels pretty sketchy; I wonder what other kinds of things could be snuck in there.

Good to know I'm not alone there; sounds like exactly the same issue. For me it would happen with both Mini DisplayPort -> HDMI and HDMI -> HDMI (on the Pro).

replied here: https://news.ycombinator.com/item?id=9806321 - switching audio to the hdmi device had no effect

I'd be suspicious about the display blinking; I used to get that and it ended up being a faulty power source (no ground, in my case).

Skype issue might just be Skype configuration; they may have their own settings for which device to use, which tends to get out of sync with OS configuration.

They'd both show up, and one (the HDMI option) would not function; it'd always send audio through the laptop. Can't play with it now as it's across the country.