8 ms·

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and bound

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps you want to manage, and want to have a couple of pipelines around those, and manage the odd Windows build target, these just give up (it's docker or bust). Sadly, only Jenkins is generic enough, much as it pains me to admit. Anyone got a sane alternative to jenkins for us poor souls?

hpaavola 7y ago
I don't think Jenkins is gui oriented, slow or hard to backup/config, but I did enjoy using TeamCity few yers back. Sure it costs you arm and a leg, but it worked well without any plugins.
allover 7y ago
> But when you have many similar repos (modules) with similar build steps you want to manage How many teams do you have? In all seriousness, if you aren't talking at least one team per repo, have you considered a monorepo setup? Aren't you burning time managing those many similar repos with many similar build steps? That said, even in a monorepo, I still prefer Jenkins compared to cleaner seeming cloud offerings due to its limitless flexibility.
- FrenchyJiby 7y ago
  Internal libraries and similar fun stuff. Common build step ~~ same packager commands run on them. Management is fairly simple with a template + seed jobs. It's just ... everything else is annoying. I don't understand what you mean by one team per repo? I agree, as I keep saying at $WORK: Jenkins is the least-worst system out there.
phowat 7y ago
I'm quite happy with Buildbot.
- tterrace 7y ago
  I'm still on buildbot, but it's definitely showing its age and I'm hoping to move off of it within a year. I've been keeping an eye on Chromium's buildbot replacement, LUCI (https://ci.chromium.org/ https://ci.chromium.org/). It's still light on documentation and the source is very internal google-y (they seem to have written their own version of virtualenv in go). However, based on the design docs it does look like they ran into a lot of the same problems I have with buildbot, specifically the lack of support for dynamic workers, and how underpowered the buildbot build steps can be. https://github.com/luci/recipes-py/blob/master/doc/user_guide.md https://github.com/luci/recipes-py/blob/master/doc/user_guid...
  - kalessin 7y ago
    Doesn't buildbot have dynamic workers implemented as latent workers? [1] What do you mean by underpowered buildbot steps? Are you implementing your own step classes? [1] https://docs.buildbot.net/current/manual/configuration/workers.html#latent-workers https://docs.buildbot.net/current/manual/configuration/worke...
    - tterrace 7y ago
      I'm not on buildbot nine (I think the new waterfall UI is a big regression), but what that is describing looks like a statically defined list of workers that scale up and down dynamically. What I'm looking for is the ability to add and remove workers at will, without having to add them to the configuration list and restart the master. In terms of underpowered build steps, I have several fairly complicated, 1k-2k line build factories, with multiple codebases and hundreds of steps (some custom, some from the stdlib). There's many dependencies between the steps, and many different properties that can be toggled in the UI. All these steps need to be defined up-front in the master, but their actual execution often depends on runtime information, so it becomes a mess of doStepIfs. I think it would be an improvement to give a program on the worker the power to tell the service what it wants to do, rather than the other way around.
chubot 7y ago
side note: I am confused by your usage of "TFA". I looked it up and it stands for what I thought it does, which has a pejorative connotation. That doesn't seem to be what you meant? https://www.urbandictionary.com/define.php?term=TFA https://www.urbandictionary.com/define.php?term=TFA
- ASalazarMX 7y ago
  It's used so much in conversation that it has ceased to be pejorative.
  - gubbrora 7y ago
    I'd argue that while RTFA had negative connotations, TFA never did. It was just a humorous reference to the former.
    - taftster 7y ago
      Agreed. I think of it more as a joking reference to RTFA. The humor of this probably originates from the early slashdot days.
  - clhodapp 7y ago
    Hrm... Totally anecdotal but I see it used that way just frequently enough that I'm familiar with the more-general usage but not nearly frequently enough for it to feel "right".
- zrail 7y ago
  I am not OP but I am 100% sure the author meant "the fucking article".
  - chubot 7y ago
    Yeah but that is derived from RTFA or RTFM, but that meaning doesn't apply here at all. I think the people using TFA don't know what it means... Whenever I see that I think they are angry about something or arguing, but he's instead supporting the point of the article. Doesn't make sense.
evv555 7y ago
>Anyone got a sane alternative to jenkins for us poor souls? I haven't tried this yet myself but AWS CodePipeline lets you have Jenkins as a stage in the pipeline. You use Jenkins only for the bits you need without the extra plugins. The resulting Jenkins box is supposed to be very lean and avoid the problems you describe.
- flowardnut 7y ago
  Performance isn't great. We're using codepipeline/codebuild (triggered via jenkins), and it's common to wait 30 seconds while the step is being created Cloudbuild on the gcp side has had much better performance
Cyph0n 7y ago
> GUI-oriented Not with pipeline files. I am a total Jenkins noob, but I was able to (relatively) quickly setup a minimal job that automatically pulls config from the relevant GH repo.
- mikepurvis 7y ago
  And prior to that there were other solutions built around manipulating the Jenkins API, eg: https://docs.openstack.org/infra/jenkins-job-builder/ https://docs.openstack.org/infra/jenkins-job-builder/ (My company switched from JJB to pipelines in the last year and has found it pretty decent.)
- twunde 7y ago
  Ah yes, pipelines do make a difference in configuring jobs. However, how are you managing your plugins? Your Jenkins configs? Most likely those are manual (however if you've found a way that works well, please share). I've also found that for some functionality, I've had to add Groovy into my pipelines. That said, pipelines has made a HUGE difference. I still want to migrate but this fixes a large pain point.
  - Cyph0n 7y ago
    Plugins and configuration are a given, but it’s something you do once upfront as part of the setup. Not sure how other tools handle this, though. And yes, you do end up needing to use Groovy for anything non-trivial.
    - unscaled 7y ago
      And then somebody needs a different, incompatible, version of plugin X and you set up another Jenkins master. Or upgrade the the Jenkins master and watch other jobs fail. And not to mention plugin Y and plugin Z crashing Jenkins when being run together because they share the same classpath. While in the meantime one of the developer is trying to migrate his pipeline from one master to another and he finds out that of course they won't work because the plugins and configuration are not exactly the same. This is exactly what OP was complaining about. You don't set up plugins and configuration just once. You want them to be replicable, but Jenkins does not provide a good way to do that. Most other CI/CD system handle this issue very simply. They just don't have plugins, and have very little (if any) global configuration. This means you can start up an entirely new cluster and chances are your pipeline files will run without a hitch.
ryanmarsh 7y ago
I'm helping clients move from Jenkins to Azure Pipelines which is part of Azure DevOps (formerly VSTS, TFS). If that doesn't make you dizzy then it's a pretty good product. It has a free tier. Windows build targets shouldn't be a problem since it's from Microsoft. Obviously it's not OSS.
mattbillenstein 7y ago
Buildkite - run your own workers using their agent, they manage the ui, it's a pretty simple system. I use it for build and test automation and it's been pretty solid.
- cmehdy 7y ago
  Have you observed any limitation or problem with it? I've been very interested in transforming our internal Jenkins CI into something lighter and modular with less maintenance which still allows multi-platform slaves, and BuildKite seems like a very interesting new player.
  - mattbillenstein 7y ago
    Not really - it's about as simple as buildbot with a nicer UI. All our builds trigger off of Github pushes - I have a handful of cheap Ubuntu VMs on Linode doing builds and tests for our code, and one Mac Mini doing builds for some developer tools - the latter is in a small rack in our office, but it works all the same. Each build pipeline is just a small shell script which does some setup and runs make to build or invokes our test entry points.
user5994461 7y ago
TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenkins and they've been around for a while.
- orlovs 7y ago
  Fine, when you are one specific vendor shop, like Jetbrains or Atlassian stack and you have got plenty of financial power, then there is always cool features, what can bring benefit. But in the end CI and CD systems are glorious semi-smart cron runners. Are these tools 10x better than Jenkins. Not so much, CI/CD is from one of the standpoint most important and in the same time less important tool, delivery should suck very much to migrate to new platform just because. Jenkins shines here, it's not perfect, but it works. More or less it's for free from licensing standpoint, you don't have to go thru Corporate procurement hell. It's not for free from workforce perspective, but none of these tools are with zero configuration. Just x,y,z, still some yaml or some other crazy configuration needs to be done (like Bamboo dsl).
  - stingraycharles 7y ago
    > But in the end CI and CD systems are glorious semi-smart cron runners. I think you’re not appreciating and misrepresenting the complexity and power that comes with these solutions.
    - megy 7y ago
      You say that, but you do not mention in what way?
      - jl-gitlab 7y ago
        You may find our direction page for CI/CD at GitLab interesting if you're looking to learn more about the possibilities involved here. We do all of our planning and roadmapping in public so you read a bit about our overall technical challenges and approach there, and drill down into the stages (CI, packaging, and CD) that make up the capabilities within GitLab, each of which have their own videos and other planning content. https://about.gitlab.com/direction/cicd/ https://about.gitlab.com/direction/cicd/
scrollaway 7y ago
Same boat as you. I'm very happy with Gitlab CI. Do look into it, it's extremely flexible. Not quite as flexible as Jenkins, but far more than Travic/Circle CI without it becoming an issue. They have an integrated Docker registry as well!
- lloeki 7y ago
  They now have configuration includes and cross project pipeline triggers, which is part of what GP seems to be looking for. Personally I’ve found that for my past and present use cases generating any needed step (e.g test matrix) e.g with a script is much more flexible, predictable, and reproducible since the generated result can be versioned. I also successfully used various custom runners including baremetal Windows ones and virtualised macOS ones inside VirtualBox.
ownagefool 7y ago
Gitlab and Concourse both support windows runners as far as I can see. They also don't require docker, but you might actually want that for most of your jobs. My biggest gripe about gitlab is you can't schedule a job in code, and I suppose it's less then ideal to support 3rd party repos in hosted gitlab, but I don't know why you'd not use it as an SCM. The bigger problem, would be using a group job that triggers a bunch of other jobs to do the many modules type of development you spoke about, but I'd just develop my modules seperatly, and build them in parallel steps if need be.
- jl-gitlab 7y ago
  Hey there, CI/CD product director here. We do allow scheduling/editing/deleting pipelines via code, at least via an API: https://docs.gitlab.com/ee/api/pipeline_schedules.html https://docs.gitlab.com/ee/api/pipeline_schedules.html Or are you looking more for putting the values in the .gitlab-ci.yml itself? This is something we have thought a bit about, but it gets strange with branches and merges where it's not always clear you're doing what the user wants as the different merges happen. To your second point, you might be interested in some of the primitives we're looking at building next here: https://about.gitlab.com/direction/cicd/#powerful-integrated-primitives https://about.gitlab.com/direction/cicd/#powerful-integrated.... These, in concert, will help with a lot of more complex workflows.
  - ownagefool 7y ago
    Indeed I meant in the .gitlab-ci.yml. I would assume you'd name the branch in the schedule, and if not default to the default branch. Similarly, it's sad you can't set a variable in one stage and have it available in another, and there's a couple of other niggles that one needs to work around. With that said, the product is fantastic and I'm just pointing out some flaws so the parent understands I've actually used the product, and not just a fanboy yelling. :)
- grzesiekb 7y ago
  We do have an issue about making it possible to use GitLab Serverless for that use-case easier. Please take a look at https://gitlab.com/gitlab-org/gitlab-ce/issues/61171 https://gitlab.com/gitlab-org/gitlab-ce/issues/61171!
rabi_penguin 7y ago
Happy Buildkite user here across two companies. We've built some custom tooling around the GraphQL API here but have since found it solid for both periodic jobs and CI needs.
kkapelon 7y ago
Check Codefresh (I work for them) https://codefresh.io/continuous-deployment/codefresh-versus-jenkins/ https://codefresh.io/continuous-deployment/codefresh-versus-... https://codefresh.io/continuous-integration/using-codefresh-with-mono-repos/ https://codefresh.io/continuous-integration/using-codefresh-...
dpods 7y ago
We run our infrastructure off of cloudflare, so we can easily spin up a staging environment that's an exact replica of production (only difference is # and size of instances). We also run a staging jenkins server that's defined in the cloudflare config. We keep our jenkins jobs version controlled by checking in each job's config.xml into a git repo. In the past I've seen the config.xml files managed by puppet or other config management tools. This helps us get around the "hard to backup" and "test in production" issues. We can test out jenkins changes in staging, commit those changes to our jenkins repo, and then push up the config.xml file to the production jenkins server when we're ready to deploy.
ay 7y ago
I’m experimenting right now with how far I can simplify the abstractions, and writing my own thing in rust. Since my use case is integration with gerrit, I poll the updated changes over ssh, and have the regex-based triggers which cause a “job” launches. Job consists of making a database entry and calling a shell script, then updating the entry upon completion. Since job is just a shell script it can kick off other jobs either serially or in parallel simply using gnu parallel :-) And voting/review is again just a command so of course is also flexible and can be made much saner than what I had seen done with Jenkins. So the “job manager” is really the OS - thus killing the “daemon” doesn’t affect the already running jobs - they will update the database as they finish. The database is SQLite with a foreseen option for Postgres. (I have made diesel optionally work with both in another two year old project which successfully provisioned and managed the event network of about 500 switches) Since I also didn’t want the HTTP daemon, the entire web interface is just monitoring, and is purely static files, regenerated upon changes. Templating for HTML done via mustache (again also use it in the other project, very happy). For fun I made (if enabled in config) the daemon reexec itself if mtime of config or the executable changes. You can look at the current state of this thing at http://s5ci-dev.myvpp.net http://s5ci-dev.myvpp.net and the associated toy gerrit instance at http://testgerrit.myvpp.net http://testgerrit.myvpp.net I am doing the first demo of this thing internally this week, and hopefully should be able to open source it. It’s about 2000 LOC of Rust and compiles using stable. Is this something that might be of use ?
- stevekemp 7y ago
  I think these kind of home-grown systems are pretty hard to "sell" to others. I know that I've written a couple, my general approach was to : * Get triggered by a github (enterprise) webhook. * Work out the project, and clone it into a temporary directory. * Launch a named docker container, bind-mounting the temporary directory to "/project" inside the image. * Once the container exits copy everything from "/output" to the host - those are the generated artifacts. There's a bit of glue to tie commit-hashes to the appropriate output, and a bit of magic to use `rsync` to allow moving output artifactes to the next container in the pipeline, if multiple steps are run. But in short I'd probably spend more time explaining the system than an experienced devops person would be creating their own version.
djhaskin987 7y ago
Zuul-ci.org had recently caught my eye, particularly because it fully supports heavy integration testing of multi-repo apps. It doesn't yet have support for bitbucket server though, which is sort of a deal breaker for me.
- RealSpamapS 7y ago
  It's just a simple matter of code. You're not the first to want BitBucket support.
heroic 7y ago
try jenkinsx. It's only named jenkins, but works without it. Supports Kubernetes only though

hpaavola 7y ago

I don't think Jenkins is gui oriented, slow or hard to backup/config, but I did enjoy using TeamCity few yers back. Sure it costs you arm and a leg, but it worked well without any plugins.

allover 7y ago

> But when you have many similar repos (modules) with similar build steps you want to manage How many teams do you have? In all seriousness, if you aren't talking at least one team per repo, have you considered a monorepo setup? Aren't you burning time managing those many similar repos with many similar build steps? That said, even in a monorepo, I still prefer Jenkins compared to cleaner seeming cloud offerings due to its limitless flexibility.

FrenchyJiby 7y ago
Internal libraries and similar fun stuff. Common build step ~~ same packager commands run on them. Management is fairly simple with a template + seed jobs. It's just ... everything else is annoying. I don't understand what you mean by one team per repo? I agree, as I keep saying at $WORK: Jenkins is the least-worst system out there.

phowat 7y ago

I'm quite happy with Buildbot.

tterrace 7y ago
I'm still on buildbot, but it's definitely showing its age and I'm hoping to move off of it within a year. I've been keeping an eye on Chromium's buildbot replacement, LUCI (https://ci.chromium.org/ https://ci.chromium.org/). It's still light on documentation and the source is very internal google-y (they seem to have written their own version of virtualenv in go). However, based on the design docs it does look like they ran into a lot of the same problems I have with buildbot, specifically the lack of support for dynamic workers, and how underpowered the buildbot build steps can be. https://github.com/luci/recipes-py/blob/master/doc/user_guide.md https://github.com/luci/recipes-py/blob/master/doc/user_guid...
- kalessin 7y ago
  Doesn't buildbot have dynamic workers implemented as latent workers? [1] What do you mean by underpowered buildbot steps? Are you implementing your own step classes? [1] https://docs.buildbot.net/current/manual/configuration/workers.html#latent-workers https://docs.buildbot.net/current/manual/configuration/worke...
  - tterrace 7y ago
    I'm not on buildbot nine (I think the new waterfall UI is a big regression), but what that is describing looks like a statically defined list of workers that scale up and down dynamically. What I'm looking for is the ability to add and remove workers at will, without having to add them to the configuration list and restart the master. In terms of underpowered build steps, I have several fairly complicated, 1k-2k line build factories, with multiple codebases and hundreds of steps (some custom, some from the stdlib). There's many dependencies between the steps, and many different properties that can be toggled in the UI. All these steps need to be defined up-front in the master, but their actual execution often depends on runtime information, so it becomes a mess of doStepIfs. I think it would be an improvement to give a program on the worker the power to tell the service what it wants to do, rather than the other way around.

chubot 7y ago

side note: I am confused by your usage of "TFA". I looked it up and it stands for what I thought it does, which has a pejorative connotation. That doesn't seem to be what you meant? https://www.urbandictionary.com/define.php?term=TFA https://www.urbandictionary.com/define.php?term=TFA

ASalazarMX 7y ago
It's used so much in conversation that it has ceased to be pejorative.
- gubbrora 7y ago
  I'd argue that while RTFA had negative connotations, TFA never did. It was just a humorous reference to the former.
  - taftster 7y ago
    Agreed. I think of it more as a joking reference to RTFA. The humor of this probably originates from the early slashdot days.
- clhodapp 7y ago
  Hrm... Totally anecdotal but I see it used that way just frequently enough that I'm familiar with the more-general usage but not nearly frequently enough for it to feel "right".
zrail 7y ago
I am not OP but I am 100% sure the author meant "the fucking article".
- chubot 7y ago
  Yeah but that is derived from RTFA or RTFM, but that meaning doesn't apply here at all. I think the people using TFA don't know what it means... Whenever I see that I think they are angry about something or arguing, but he's instead supporting the point of the article. Doesn't make sense.

evv555 7y ago

>Anyone got a sane alternative to jenkins for us poor souls? I haven't tried this yet myself but AWS CodePipeline lets you have Jenkins as a stage in the pipeline. You use Jenkins only for the bits you need without the extra plugins. The resulting Jenkins box is supposed to be very lean and avoid the problems you describe.

flowardnut 7y ago
Performance isn't great. We're using codepipeline/codebuild (triggered via jenkins), and it's common to wait 30 seconds while the step is being created Cloudbuild on the gcp side has had much better performance

Cyph0n 7y ago

> GUI-oriented Not with pipeline files. I am a total Jenkins noob, but I was able to (relatively) quickly setup a minimal job that automatically pulls config from the relevant GH repo.

mikepurvis 7y ago
And prior to that there were other solutions built around manipulating the Jenkins API, eg: https://docs.openstack.org/infra/jenkins-job-builder/ https://docs.openstack.org/infra/jenkins-job-builder/ (My company switched from JJB to pipelines in the last year and has found it pretty decent.)
twunde 7y ago
Ah yes, pipelines do make a difference in configuring jobs. However, how are you managing your plugins? Your Jenkins configs? Most likely those are manual (however if you've found a way that works well, please share). I've also found that for some functionality, I've had to add Groovy into my pipelines. That said, pipelines has made a HUGE difference. I still want to migrate but this fixes a large pain point.
- Cyph0n 7y ago
  Plugins and configuration are a given, but it’s something you do once upfront as part of the setup. Not sure how other tools handle this, though. And yes, you do end up needing to use Groovy for anything non-trivial.
  - unscaled 7y ago
    And then somebody needs a different, incompatible, version of plugin X and you set up another Jenkins master. Or upgrade the the Jenkins master and watch other jobs fail. And not to mention plugin Y and plugin Z crashing Jenkins when being run together because they share the same classpath. While in the meantime one of the developer is trying to migrate his pipeline from one master to another and he finds out that of course they won't work because the plugins and configuration are not exactly the same. This is exactly what OP was complaining about. You don't set up plugins and configuration just once. You want them to be replicable, but Jenkins does not provide a good way to do that. Most other CI/CD system handle this issue very simply. They just don't have plugins, and have very little (if any) global configuration. This means you can start up an entirely new cluster and chances are your pipeline files will run without a hitch.

ryanmarsh 7y ago

I'm helping clients move from Jenkins to Azure Pipelines which is part of Azure DevOps (formerly VSTS, TFS). If that doesn't make you dizzy then it's a pretty good product. It has a free tier. Windows build targets shouldn't be a problem since it's from Microsoft. Obviously it's not OSS.

mattbillenstein 7y ago

Buildkite - run your own workers using their agent, they manage the ui, it's a pretty simple system. I use it for build and test automation and it's been pretty solid.

cmehdy 7y ago
Have you observed any limitation or problem with it? I've been very interested in transforming our internal Jenkins CI into something lighter and modular with less maintenance which still allows multi-platform slaves, and BuildKite seems like a very interesting new player.
- mattbillenstein 7y ago
  Not really - it's about as simple as buildbot with a nicer UI. All our builds trigger off of Github pushes - I have a handful of cheap Ubuntu VMs on Linode doing builds and tests for our code, and one Mac Mini doing builds for some developer tools - the latter is in a small rack in our office, but it works all the same. Each build pipeline is just a small shell script which does some setup and runs make to build or invokes our test entry points.

user5994461 7y ago

TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenkins and they've been around for a while.

orlovs 7y ago
Fine, when you are one specific vendor shop, like Jetbrains or Atlassian stack and you have got plenty of financial power, then there is always cool features, what can bring benefit. But in the end CI and CD systems are glorious semi-smart cron runners. Are these tools 10x better than Jenkins. Not so much, CI/CD is from one of the standpoint most important and in the same time less important tool, delivery should suck very much to migrate to new platform just because. Jenkins shines here, it's not perfect, but it works. More or less it's for free from licensing standpoint, you don't have to go thru Corporate procurement hell. It's not for free from workforce perspective, but none of these tools are with zero configuration. Just x,y,z, still some yaml or some other crazy configuration needs to be done (like Bamboo dsl).
- stingraycharles 7y ago
  > But in the end CI and CD systems are glorious semi-smart cron runners. I think you’re not appreciating and misrepresenting the complexity and power that comes with these solutions.
  - megy 7y ago
    You say that, but you do not mention in what way?
    - jl-gitlab 7y ago
      You may find our direction page for CI/CD at GitLab interesting if you're looking to learn more about the possibilities involved here. We do all of our planning and roadmapping in public so you read a bit about our overall technical challenges and approach there, and drill down into the stages (CI, packaging, and CD) that make up the capabilities within GitLab, each of which have their own videos and other planning content. https://about.gitlab.com/direction/cicd/ https://about.gitlab.com/direction/cicd/

scrollaway 7y ago

Same boat as you. I'm very happy with Gitlab CI. Do look into it, it's extremely flexible. Not quite as flexible as Jenkins, but far more than Travic/Circle CI without it becoming an issue. They have an integrated Docker registry as well!

lloeki 7y ago
They now have configuration includes and cross project pipeline triggers, which is part of what GP seems to be looking for. Personally I’ve found that for my past and present use cases generating any needed step (e.g test matrix) e.g with a script is much more flexible, predictable, and reproducible since the generated result can be versioned. I also successfully used various custom runners including baremetal Windows ones and virtualised macOS ones inside VirtualBox.

ownagefool 7y ago

Gitlab and Concourse both support windows runners as far as I can see. They also don't require docker, but you might actually want that for most of your jobs. My biggest gripe about gitlab is you can't schedule a job in code, and I suppose it's less then ideal to support 3rd party repos in hosted gitlab, but I don't know why you'd not use it as an SCM. The bigger problem, would be using a group job that triggers a bunch of other jobs to do the many modules type of development you spoke about, but I'd just develop my modules seperatly, and build them in parallel steps if need be.

jl-gitlab 7y ago
Hey there, CI/CD product director here. We do allow scheduling/editing/deleting pipelines via code, at least via an API: https://docs.gitlab.com/ee/api/pipeline_schedules.html https://docs.gitlab.com/ee/api/pipeline_schedules.html Or are you looking more for putting the values in the .gitlab-ci.yml itself? This is something we have thought a bit about, but it gets strange with branches and merges where it's not always clear you're doing what the user wants as the different merges happen. To your second point, you might be interested in some of the primitives we're looking at building next here: https://about.gitlab.com/direction/cicd/#powerful-integrated-primitives https://about.gitlab.com/direction/cicd/#powerful-integrated.... These, in concert, will help with a lot of more complex workflows.
- ownagefool 7y ago
  Indeed I meant in the .gitlab-ci.yml. I would assume you'd name the branch in the schedule, and if not default to the default branch. Similarly, it's sad you can't set a variable in one stage and have it available in another, and there's a couple of other niggles that one needs to work around. With that said, the product is fantastic and I'm just pointing out some flaws so the parent understands I've actually used the product, and not just a fanboy yelling. :)
grzesiekb 7y ago
We do have an issue about making it possible to use GitLab Serverless for that use-case easier. Please take a look at https://gitlab.com/gitlab-org/gitlab-ce/issues/61171 https://gitlab.com/gitlab-org/gitlab-ce/issues/61171!

rabi_penguin 7y ago

Happy Buildkite user here across two companies. We've built some custom tooling around the GraphQL API here but have since found it solid for both periodic jobs and CI needs.

kkapelon 7y ago

Check Codefresh (I work for them) https://codefresh.io/continuous-deployment/codefresh-versus-jenkins/ https://codefresh.io/continuous-deployment/codefresh-versus-... https://codefresh.io/continuous-integration/using-codefresh-with-mono-repos/ https://codefresh.io/continuous-integration/using-codefresh-...

dpods 7y ago

We run our infrastructure off of cloudflare, so we can easily spin up a staging environment that's an exact replica of production (only difference is # and size of instances). We also run a staging jenkins server that's defined in the cloudflare config. We keep our jenkins jobs version controlled by checking in each job's config.xml into a git repo. In the past I've seen the config.xml files managed by puppet or other config management tools. This helps us get around the "hard to backup" and "test in production" issues. We can test out jenkins changes in staging, commit those changes to our jenkins repo, and then push up the config.xml file to the production jenkins server when we're ready to deploy.

ay 7y ago

I’m experimenting right now with how far I can simplify the abstractions, and writing my own thing in rust. Since my use case is integration with gerrit, I poll the updated changes over ssh, and have the regex-based triggers which cause a “job” launches. Job consists of making a database entry and calling a shell script, then updating the entry upon completion. Since job is just a shell script it can kick off other jobs either serially or in parallel simply using gnu parallel :-) And voting/review is again just a command so of course is also flexible and can be made much saner than what I had seen done with Jenkins. So the “job manager” is really the OS - thus killing the “daemon” doesn’t affect the already running jobs - they will update the database as they finish. The database is SQLite with a foreseen option for Postgres. (I have made diesel optionally work with both in another two year old project which successfully provisioned and managed the event network of about 500 switches) Since I also didn’t want the HTTP daemon, the entire web interface is just monitoring, and is purely static files, regenerated upon changes. Templating for HTML done via mustache (again also use it in the other project, very happy). For fun I made (if enabled in config) the daemon reexec itself if mtime of config or the executable changes. You can look at the current state of this thing at http://s5ci-dev.myvpp.net http://s5ci-dev.myvpp.net and the associated toy gerrit instance at http://testgerrit.myvpp.net http://testgerrit.myvpp.net I am doing the first demo of this thing internally this week, and hopefully should be able to open source it. It’s about 2000 LOC of Rust and compiles using stable. Is this something that might be of use ?

stevekemp 7y ago
I think these kind of home-grown systems are pretty hard to "sell" to others. I know that I've written a couple, my general approach was to : * Get triggered by a github (enterprise) webhook. * Work out the project, and clone it into a temporary directory. * Launch a named docker container, bind-mounting the temporary directory to "/project" inside the image. * Once the container exits copy everything from "/output" to the host - those are the generated artifacts. There's a bit of glue to tie commit-hashes to the appropriate output, and a bit of magic to use `rsync` to allow moving output artifactes to the next container in the pipeline, if multiple steps are run. But in short I'd probably spend more time explaining the system than an experienced devops person would be creating their own version.

djhaskin987 7y ago

Zuul-ci.org had recently caught my eye, particularly because it fully supports heavy integration testing of multi-repo apps. It doesn't yet have support for bitbucket server though, which is sort of a deal breaker for me.

RealSpamapS 7y ago
It's just a simple matter of code. You're not the first to want BitBucket support.

heroic 7y ago

try jenkinsx. It's only named jenkins, but works without it. Supports Kubernetes only though