7 ms·

My thoughts exactly, this is a perfect use case for Jenkins. Talk about reinventing the wheel!

rhinoceraptor 8y ago
I always find Jenkins to be an absolute nightmare. The IT/“devops” people hand install it (most likely on your incredibly unreliable on-prem VSphere or whatever) and then immediately forget about it. Of course, mere developers aren’t not capable of such a feat of system administration as installing Jenkins. Then three months later when it starts failing due to disk space or memory issues you have to beg them to fix it so you can keep working.
- humbleMouse 8y ago
  Sounds like your problem is with your admin department and not jenkins...
  - setquk 8y ago
    As the admin department of a company that runs Jenkins, it’s the second worst thing we have to keep alive (black duck software was the worst). Jenkins is leaky, unstable, unfriendly to the filesystem, buggy and poorly documented and tested. If you’re going to do anything like this it’s actually worth paying for team city or something else.
    - tslug 8y ago
      Agreed. In a gig last year, I needed to improve the build turnaround times on a Jenkins system. After learning everything I could about Jenkins, I realized the correct answer was to delete it and rewrite my own version that ran on the local system, which was way, way faster and much easier to debug and maintain. Not having to commit/upload your code to a build server and then wait to get an executable/package back is an enormous time-saver just in that overhead alone, but even the build itself was faster, even though it was written entirely in bashscript. Go figure.
- Consultant32452 8y ago
  "Hey, I need this free plugin or I can't even build my app." "Maybe next year we'll have time to look into your plugin."
  - gaius 8y ago
    After the first couple hundred "free" plugins you will find that you pay in other ways - this is the same in anything that supports a plugin. In any system I manage the cost of the plugin simply isn't an issue - if it's worth the money, it's easy to justify paying. But if it's free, and it becomes critical to the workflow, and in a year's time the author has abandoned it, then the "cost" is that we assume the responsibility for maintaining it forever, or we retool the workflow, or in some other way, it's very expensive. So paradoxically paid-for plugins are a much easier sell and requests for free stuff are shot down straight away.
    - Consultant32452 8y ago
      I really dislike this anti-helpful attitude. If there's a better/for-pay option that you prefer, suggest it.
- rhacker 8y ago
  I would have to agree with this. I don't know what state of the art Jenkins is in now, but our company does infrastructure as code. I don't think Jenkin's would pass muster. I think we would see the UI as a major liability as time goes on. If we ever needed to migrate off the instance of Jenkins or a plugin is no longer supported, or a million other things, Jenkins is a rather large deployment for running scheduled tasks. There would be too many specialized things installed or hand manipulated for us. We already had major issues with another company basically hiding a lot of packed crap all over the place, so infrastructure as code has helped a lot. We ended up writing 114 line typescript job scheduler that uses Mongodb as a store. Mongodb provides the atomicity of scheduling (find and modify). Beyond that our UI is Robo 3T. The job collection has 4 simple states. Any process can write a job document with the earliest time the document can run. It is also scaled with the rest of our application: more instances, more jobs that can run simultaneously. But... I can see in shops that don't have this complexity yet, Jenkins might be just fine. Edit to add: We decided against using another data source like a Queue which is something we would have used a long time ago, but we're already at an infrastructure complexity point where it would not be worth it - we already have Elasticsearch, MongoDB and Mysql so adding a AWS queue or rabbit would be out of the question at this point unless it provided a massive functionality we would need for something else.
  - tomnipotent 8y ago
    > But... I can see in shops that don't have this complexity yet, Jenkins might be just fine. It sounds like you have a very simple collection of jobs running that lack run-time complexity like remote hosts being unavailable or preventing a service from being overloaded with requests after it comes online because you have an ever-growing list of tasks waiting. The actual complexities of DAG-based workflow management tools are considerably more complex than can be expressed in 114 lines of any language, and I hope any programmer I work with would spare me and my peers the misery of trying to roll and maintain our own when plenty of open source and actively maintained projects fit the bill that could benefit from our contributions.
    - rhacker 8y ago
      Yep that is true, our jobs have no forward or reverse dependencies, no knowledge of what came first or what is next. Just a scheduler. If I picked up an open source tool, our company would be in process hell including managing how to integrate it with our stack. I don't know why you would mention this because you don't have the requirements I have. If I had solved all scheduling needs for all people in 114 lines of code I would have written so.
- bogomipz 8y ago
  >"I always find Jenkins to be an absolute nightmare." Nothing you go on to detail after that opening sentence has anything to do with Jenkins itself but rather your company and it's organization.
- chrismorgan 8y ago
  Never mind: you can very probably find a security vulnerability that you can exploit to take over the machine so you can maintain it all yourself.
- liveoneggs 8y ago
  it was all "devops" and "self service" until you couldn't figure out how to click "discard old builds", eh?
nradov 8y ago
If engineers didn't constantly reinvent the wheel they wouldn't have anything to blog about.
- travbrack 8y ago
  This is my favorite comment on hackernews so far

I always find Jenkins to be an absolute nightmare. The IT/“devops” people hand install it (most likely on your incredibly unreliable on-prem VSphere or whatever) and then immediately forget about it. Of course, mere developers aren’t not capable of such a feat of system administration as installing Jenkins. Then three months later when it starts failing due to disk space or memory issues you have to beg them to fix it so you can keep working.

humbleMouse 8y ago
Sounds like your problem is with your admin department and not jenkins...
- setquk 8y ago
  As the admin department of a company that runs Jenkins, it’s the second worst thing we have to keep alive (black duck software was the worst). Jenkins is leaky, unstable, unfriendly to the filesystem, buggy and poorly documented and tested. If you’re going to do anything like this it’s actually worth paying for team city or something else.
  - tslug 8y ago
    Agreed. In a gig last year, I needed to improve the build turnaround times on a Jenkins system. After learning everything I could about Jenkins, I realized the correct answer was to delete it and rewrite my own version that ran on the local system, which was way, way faster and much easier to debug and maintain. Not having to commit/upload your code to a build server and then wait to get an executable/package back is an enormous time-saver just in that overhead alone, but even the build itself was faster, even though it was written entirely in bashscript. Go figure.
Consultant32452 8y ago
"Hey, I need this free plugin or I can't even build my app." "Maybe next year we'll have time to look into your plugin."
- gaius 8y ago
  After the first couple hundred "free" plugins you will find that you pay in other ways - this is the same in anything that supports a plugin. In any system I manage the cost of the plugin simply isn't an issue - if it's worth the money, it's easy to justify paying. But if it's free, and it becomes critical to the workflow, and in a year's time the author has abandoned it, then the "cost" is that we assume the responsibility for maintaining it forever, or we retool the workflow, or in some other way, it's very expensive. So paradoxically paid-for plugins are a much easier sell and requests for free stuff are shot down straight away.
  - Consultant32452 8y ago
    I really dislike this anti-helpful attitude. If there's a better/for-pay option that you prefer, suggest it.
rhacker 8y ago
I would have to agree with this. I don't know what state of the art Jenkins is in now, but our company does infrastructure as code. I don't think Jenkin's would pass muster. I think we would see the UI as a major liability as time goes on. If we ever needed to migrate off the instance of Jenkins or a plugin is no longer supported, or a million other things, Jenkins is a rather large deployment for running scheduled tasks. There would be too many specialized things installed or hand manipulated for us. We already had major issues with another company basically hiding a lot of packed crap all over the place, so infrastructure as code has helped a lot. We ended up writing 114 line typescript job scheduler that uses Mongodb as a store. Mongodb provides the atomicity of scheduling (find and modify). Beyond that our UI is Robo 3T. The job collection has 4 simple states. Any process can write a job document with the earliest time the document can run. It is also scaled with the rest of our application: more instances, more jobs that can run simultaneously. But... I can see in shops that don't have this complexity yet, Jenkins might be just fine. Edit to add: We decided against using another data source like a Queue which is something we would have used a long time ago, but we're already at an infrastructure complexity point where it would not be worth it - we already have Elasticsearch, MongoDB and Mysql so adding a AWS queue or rabbit would be out of the question at this point unless it provided a massive functionality we would need for something else.
- tomnipotent 8y ago
  > But... I can see in shops that don't have this complexity yet, Jenkins might be just fine. It sounds like you have a very simple collection of jobs running that lack run-time complexity like remote hosts being unavailable or preventing a service from being overloaded with requests after it comes online because you have an ever-growing list of tasks waiting. The actual complexities of DAG-based workflow management tools are considerably more complex than can be expressed in 114 lines of any language, and I hope any programmer I work with would spare me and my peers the misery of trying to roll and maintain our own when plenty of open source and actively maintained projects fit the bill that could benefit from our contributions.
  - rhacker 8y ago
    Yep that is true, our jobs have no forward or reverse dependencies, no knowledge of what came first or what is next. Just a scheduler. If I picked up an open source tool, our company would be in process hell including managing how to integrate it with our stack. I don't know why you would mention this because you don't have the requirements I have. If I had solved all scheduling needs for all people in 114 lines of code I would have written so.
bogomipz 8y ago
>"I always find Jenkins to be an absolute nightmare." Nothing you go on to detail after that opening sentence has anything to do with Jenkins itself but rather your company and it's organization.
chrismorgan 8y ago
Never mind: you can very probably find a security vulnerability that you can exploit to take over the machine so you can maintain it all yourself.
liveoneggs 8y ago
it was all "devops" and "self service" until you couldn't figure out how to click "discard old builds", eh?

nradov 8y ago

If engineers didn't constantly reinvent the wheel they wouldn't have anything to blog about.

travbrack 8y ago
This is my favorite comment on hackernews so far