GNOME's BuildStream Reaches v1.0

[phoronix]

Phoronix: GNOME's BuildStream Reaches v1.0

GNOME's BuildStream project has declared its first stable release, v1.0, after being in development for the past year...

http://www.phoronix.com/scan.php?page=news_item&px=GNOME-BuildStream-1.0

[FishPls]

in YAML format

Oh god, why? YAML is about the worst format you could choose, TOML would've been a lot saner of a choice. Every single YAML parser parses YAML differently because it's a clusterfuck of a standard. I especially hate YAML's implicit typing.

[bregma]

Like all things GNOME, this system is strongly driven by NIH (and I don't necessarily hold that to be a negative criticism). That said, it's the wild wild west still in the integrated build system world, and the design and philosophy behind this one is solid and consistent with adherence to dogma and it stands a good chance of becoming a healthy member of the peloton behind the systems that are driven more by pragmatism and flexibility and an eye on a revenue stream.

[Michael_S]

I'll have to watch the 45 minute GUADEC ( GNOME's Annual User and Developer European Conference) video about the project linked from the main page. I wonder why they're unhappy with Jenkins?

Jenkins isn't especially pretty, but it's free software and supports incredible customization through plugins.

Oh god, why? YAML is about the worst format you could choose, TOML would've been a lot saner of a choice. Every single YAML parser parses YAML differently because it's a clusterfuck of a standard. I especially hate YAML's implicit typing.

We use Saltstack for configuration management at work, and its default configuration file format is YAML. At this point I've climbed the learning curve and survived all the times it stabbed me in the back. I agree with your point, YAML is an unfortunate choice.

[starshipeleven]

YAML is about the worst format you could choose

Amen to that. For those wondering: https://github.com/cblp/yaml-sucks

[Michael_S]

Okay, I watched part of the video and read some of the documentation. I can see why Jenkins was a poor fit for what they wanted.

I'm not a Jenkins expert, but the way we use Jenkins at work and the way I understand most places use it is that there are central Jenkins servers that are the responsibility of one person or team to manage and configure. Different users in the organization have different permissions to view, run, or configure specific jobs. The individual Jenkins jobs can have dependencies with each other, trigger on a schedule, start other jobs, and so forth and may interact with git or svn or just run arbitrary shell scripts. Job logs and histories are stored long term, though you can turn it off on a per-job basis.

- BuildStream operates from the command line, so it's not default web-driven like Jenkins. Jenkins offers some kind of command line support, but my impression is that it's not typical or well-documented how to handle your entire continuous integration system with Jenkins that way.

- Jenkins setups assume some kind of centralized deployment. I think the goal for BuildStream is to have all GNOME developers, or all developers on any project that adopts the tool, use it on their own workstations and servers. You use it to automate your local workflow and not just your project/company remote workflow.

- BuildStream is more like a meta-build system. It can download, optionally compile, and cache dependencies like Java Maven or Python pip. You can pipeline tasks together. You can trigger tasks. All of that can be done with Maven or probably pip or others, but you have to manage the hand-off between your tools yourself with plugins or shell scripts. BuildStream handles all of it for you. Like Maven (and presumably other build systems, I just know Maven best) you can set it up to publish artifacts to a shared artifact repo so that not everyone on the team needs to recompile a new version of WebKit or some other big shared component.

- BuildStream is, or will, support cross-platform builds and building virtualized environments. The project developers want someone to be able to run a build and have the results tested automatically in Debian and Fedora, or Debian on ARM, and so forth without having to push to a central repository and wait for feedback.

Hopefully I understood the documentation well enough and that's all accurate.