Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jenkins 2.0 Beta

jenkins.io

Post reply on HN
Print view View original

121–130 of 157 posts

Re: Jenkins 2.0 Beta

#121

Post by pron »

incepted wrote: post #113
pron wrote: post #111

Earlier quoted context omitted.

> I think the future belongs to statically typed languages that can offer DSL's as terse as Groovy but with actually types in them, so that the IDE can actually do the job it's being paid for. Not as easy as it sounds. If the DSL is rich enough, and if the types are handled by the host language, type errors can become just as cryptic and unhelpful as with an untyped DSLs, and it's just as hard for the IDE to do somet…

Sure, but at least, auto completion works automatically. With dynamically typed languages, you get cryptic (and vague) errors and auto completion just can't work.

That also depends on the namespaces used by the language. E.g. auto-completion in Clojure works a lot better than in JS, because every symbol has a unique resolution, known statically (or as unique as in many typed languages). True, you get less helpful suggestions, but OTOH, the error messages can be much clearer than in the typed case. The former can leave error reporting to the DSL, while the latter is restricted to the cryptic types of the host language's compiler. I'm not saying this can't be resolved with some clever compiler plugins, but if we're comparing options available now, the advantage is not so clear-cut (I do favor types, but only as long as they don't get too complex).

Re: Jenkins 2.0 Beta

#122

Post by ipsi »

vito wrote: post #96
genericpenguin wrote: post #90

Earlier quoted context omitted.

I've been a heavy Jenkins user for the last three years and I can completely see where you (and Concourse team) are coming from. The page comparing Jenkins and Concourse hits all my right buttons (complexity in build specification, minimal pipeline, etc) but I find that having to BOSH the hell out of a new system (pun intended) just to get CI running seems like a PITA to me (it's the one thing preventing me from reco…

@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 Gi…

Does this mean it will be (is?) possible to deploy Concourse on a single machine without the headache of BOSH Lite? I've wanted to use Concourse, but when all you've got is a Mac Mini, doing a full BOSH deploy (or even BOSH Lite) is quite a big ask.

Re: Jenkins 2.0 Beta

#123

Post by code_research »

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts.

Could developers of these tools please stop dictating where people have to put the "Blahfile" dsl config files and finally allow people to configure these kind of details.

Also I would like to propose a common standard directory "projectroot/config" for these kind of files, NOT the project root directory itself.

Thanks for your attention!

Re: Jenkins 2.0 Beta

#124

Post by kbody »

code_research wrote: post #123

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts. Could developers of these tools please stop dictating where people have to put the "Blahfile" dsl config files and finally allow people to configure these kind of details. Also I would like to propose a common standard directory "projectroot/config" for these kind of…

"projectroot/config" it's too common and already used in different ways that will produce conflicts. If something is established it should be done in a proper way through a spec like semver was established.

Re: Jenkins 2.0 Beta

#125

Post by code_research »

kbody wrote: post #124
code_research wrote: post #123

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts. Could developers of these tools please stop dictating where people have to put the "Blahfile" dsl config files and finally allow people to configure these kind of details. Also I would like to propose a common standard directory "projectroot/config" for these kind of…

"projectroot/config" it's too common and already used in different ways that will produce conflicts. If something is established it should be done in a proper way through a spec like semver was established.

you could avoid conflicts by not naming your project files "Dockerfile" or "Jenkinsfile" or "travis.yml"...

Re: Jenkins 2.0 Beta

#126

Post by jacques_chester »

ABS wrote: post #43
jacques_chester wrote: post #13

It's great to see that Jenkins is following the path blazed by GoCD[1] and Concourse[2] to make the pipeline concept more central. That said, this appears to be achieved by promoting the plugin into the default installation. It also misses some of additional the advantage Concourse holds over Jenkins and GoCD: build configuration is purely declarative and can be checked in with the project. You know what version of y…

GoCD pipeline config is actually (sort of) declarative and stored in XML format in an internal git repo so it's versioned and you can recover/replay any version of it (in fact you can visualize the very first version of a pipeline you ran 3 years ago in the Value Stream Map visualisation and execute it again). Agreed that the format isn't ideal but there are non-trivial problems in breaking it down due to the advance…

Concourse avoids the fan-in/fan-out problems of GoCD's XML configuration by performing planning for you.

That is, you define the inputs and outputs of a job, then Concourse derives how to carry out your jobs in the correct order under the correct conditions.

A Concourse yaml file is pretty flat, as a consequence.

That's a great writeup. I think you'd find Concourse attractive.

Re: Jenkins 2.0 Beta

#127

Post by jacques_chester »

twic wrote: post #97
dprotaso wrote: post #92

Earlier quoted context omitted.

No need to fork anymore http://concourse.ci/configuring-resource-types.html

Oho! That's excellent. I see that came in 0.74; we're still on 0.70 i think, so i look forward even more to upgrading.

Yeah, a few of us griped at the Concourse team about this large escape hatch from historical reproducibility and they took us seriously.

Re: Jenkins 2.0 Beta

#128

Post by jacques_chester »

code_research wrote: post #123

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts. Could developers of these tools please stop dictating where people have to put the "Blahfile" dsl config files and finally allow people to configure these kind of details. Also I would like to propose a common standard directory "projectroot/config" for these kind of…

I've had this thought too, but I think the horses have well and truly bolted.

Concourse lets you put the file anywhere; the act of applying configuration is distinct from committing it.

Initially people put `pipeline.yml` or `concourse.yml` files in the top of their repo.

It's rapidly evolved so that typically you'll find either `ci/pipelines/{some,number,of,pipelines}.yml` in the main repo, or a separate repo for the CI/CD system. I prefer the former, most teams I've seen so far prefer the latter.

Re: Jenkins 2.0 Beta

#129

Post by jacques_chester »

derFunk wrote: post #74
Alupis wrote: post #3

I've been using Jenkins for years, and have been overwhelmingly happy. 2.0 is a big step for the project, congrats! The flexibility Jenkins provides as build system is enormous. The plugin community is also a huge benefit -- chances are, if you have a need, there's a plugin for it.

I feel the same. Using Jenkins since 5 years now on a daily basis. Yet I also feel it may be coming too late. During the past 5 years our projects have grown to a size were we're expecting to have more than 1m DAU end of this year, and I don't think Jenkins will survive this journey with us. I'm speaking about scripted Docker container baking & deployments to e.g. ECS, ECR, asset uploads and versioning, basically rel…

> I'm looking for modern solutions for the latter which is basically as stateless and reliable as our product Docker infrastructure.

I'm a broken record in this thread: Concourse. Stateless, containerised builds. Declarative config checked into repos. Pipelines as the central concept.

All of these as the core paradigm, not from plugins.

Re: Jenkins 2.0 Beta

#130

Post by Roritharr »

sytse wrote: post #31

It is clear that build stages should be first class citizens. We based GitLab CI on the awesome work that GoCD and Concourse did in this respect. Our DSL allows you to assign jobs to stages https://gitlab.com/gitlab-org/gitlab-ce/blob/43e49f52e30199c... and jenkins seems to have picked a similar syntax. What is interesting is that Jenkins has a DSL but that this is not part of the repository. This means that it is ha…

I might be an absolute DevOps Newbie, but getting GitLab CI to do a simple "copy to this ssh destination" buildscript seems very complicated.

From what I could gather it means that I have to create a specific runner whose login credentials are in its config, which aren't accessible via the WebUi, only as a file on the server where the runner is running and give it an unique tag. Then in my repofile i have to select that specific runner so it then "runs the build" on my deployment target.

Hopefully i'm completely wrong about this, but this seems horribly complicated and very inflexible for deployment purposes. Why would I specify my deployment target in my repo?

Maybe simple deployment jobs like I'd build them in Jenkins aren't in the scope for GitLab CI?

Post reply on HN