6 ms·

Definitely look at Jenkins. You can do pretty much whatever you want with it (not always a good thing though of course, use responsibly)

• Waterluvian 6y ago
  Jenkins is powerful and painfully complex. You might need that complexity for large projects but personally I've found it to be so frustrating to set up simple stuff.
  • hinkley 6y ago
    As we discussed in a previous thread, the features tend to become a trap of lock-in. Often better to have your scripts do most of the work and the build tool handle triggers, bookkeeping, and some statistics.
    • cghendrix 6y ago
      That does seem like the best practice.
• jniedrauer 6y ago
  Chiming in to say: Avoid Jenkins like the plague. Jenkins is a bottomless pit of vulnerabilities and obscure bugs and outdated documentation that will waste weeks of your life. (Caveat: If you plan to do devops at a Big Corp, then you might as well get good at Jenkins because they already use it.)
  • mschuster91 6y ago
    Gitlab CI could almost replace Jenkins. I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment". Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job instead of reusing the same environment, slower than Jenkins which does matter for some people. A particularly dumb case showing this is when something needs to be done on a remote server via ssh - in Jenkins, one has to click "SSH Agent", choose the credential, and you can use "ssh user@host" just fine and do whatever you want. In Gitlab CI, one has to check if ssh is available on the runner image, install it if it isn't present, eval ssh-agent, and only then it works - and all of this needs to be re-done at each run (additionally meaning that your jobs have a dependency on an Internet connection plus the distribution's package servers!). In Jenkins, with a proper tool configuration I can specify something like Maven or NodeJS and Jenkins will automatically install the tool if it is not present and then never again while in Gitlab, again, as it's stateless all will need to be re-done every single build time.
    • jniedrauer 6y ago
      That's a good point, there is a vacuum for a good general purpose task automation tool that Jenkins has historically filled. The problem is that each of the magic functions you listed above are separate plugins. They're not part of Jenkins itself. Each plugin may (and often will) push breaking changes and vulnerabilities to your Jenkins instance, if they haven't been outright abandoned by their maintainers. Over time, your builds will steadily accumulate hacks to work around broken plugins, and your Jenkins instance rots.
      • saurik 6y ago
        The same is largely true of GitHub Actions... so don't use any: wit you have Jenkin's doing anything other than task management and running shell scripts you maintain, I'd argue strongly you are doing it all wrong (as if nothing else you are buying into lock-in for no reason).
    • Rmblnm4n 6y ago
      In-house micro services could solve this. Then SRE is eating the Kube dog food. Semantic games are the only reason there’s a gap between dev and SRE work anymore. It’s all HTTP/RESTY APIs with ACLs on who can GET versus GET+PUT Snapshot state to DocumentDB and rerun it through AWS SDK based services. The cloud ops world has gone utterly bonkers with tool sprawl.
    • TylerE 6y ago
      Couldn't you do something like have a dummy repo just for trigger things, and then make commits to it via cron?
    • digi59404 6y ago
      Hey op - Wanted to chime in here some of the things you said aren’t accurate anymore. GitLab CI has the ability to do SSH on the Runners. You deploy a runner and configure it to use SSH. Then it won’t use containers at all and instead use SSH. The same is true for configuring the runner in a shell capacity. You can then reuse the same environments over and over just like Jenkins does. As for Maven and NodeJS if you’re using containers, you simply build a dockerimage with those baked in, and use it for your builds. GitLab also has container storage that allows your images to work seem less and quickly with the runners. For independent tasks without commits. You can easily configure a gitlab job to trigger only if a pipeline variable is present. Then trigger the pipeline via HTTP POST Request, via the UI or vi an event. I talk about and demonstrate all of these topics on my blog www.lackastack.com - Shameless plug, but I hope it helps.
  • cghendrix 6y ago
    Yeah been years since I used it and forgot about this. Very true. (and yep used it at several big corps)