7 ms·

>do the minimum with these CI integrations to get my shell script to run This. 100%. Where I'm working is migrating from Bamboo to Jenkins. For my team the new

>do the minimum with these CI integrations to get my shell script to run This. 100%. Where I'm working is migrating from Bamboo to Jenkins. For my team the new process is just calling "./build-test $params" while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git.

redis_mlc 6y ago
I call mine make.sh. Now get off my lawn!
- monkeybutton 6y ago
  Hey! I started with C projects and make scripts and I long for the simplicity of those days! Obtuse web front ends, bunches of build server pools segregated by random capabilities, job queues clogged by competing developer teams and on and on is no fun.
- saurik 6y ago
  I wouldn't want something called "make.sh" to install tooling on the computer, though, and that is an important step of CI stuff.
  - aprdm 6y ago
    Run it in a docker container so that it does the same in your computer and in the CI worker. make prepare make build make test make release Working the same waylocally and in jenkins makes things very easy. What it does is up to the team but make prepare usually pulls some docker image and install dependencies, make build builds something inside the docker image, make test runs test inside it and make release publishes the docker img
    - laumars 6y ago
      Or use a CI/CD tool that natively supports Docker, like Concourse. Added bonus is that pipelines are defined in YAML rather than web GUI so you can version control the pipelines themselves and not just any build or test suites.
      - aprdm 6y ago
        Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). I have heard good things about Concourse, want to give it a try in the future!
        laumars 6y ago
        > Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). There's several ways you can codify Jenkins pipelines, Groovy being just one of them. But ultimately it's secondary to the main design of Jenkins. I'm not taking anything away from Jenkins as a solution - it has been invaluable over the years. But the way we write, test and deploy software has changed since Jenkins rose in popularity and as such we need to rely on different workflows that utilise different tooling. While Jenkins can be used in that way, I'd sooner use something which was primarily designed to be configured via code and used docker by default rather than something that requires enforcement to follow those best practices. That doesn't necessarily mean Concourse, there's Travis, Circle CI, AWS CodeBuild and a bunch of others that all default to that kind of workflow too, but it does mean I'm unlikely to ever advocate Jenkins again in future jobs.
        aprdm 6y ago
        While you’re not wrong I do use jenkins inside docker and use ansible to configure it, it is a bit different than other more modern tools but works fine. I have yet to see other tools be as flexible (perforce , git, legacy tools, docker, 100s of workers across datacenters etc.)
        6y ago
    - redis_mlc 6y ago
      I think you missed the plot here. make.sh is instead of Docker, CI workers, fancy stuff, etc. :) It's for developers who care more about results than resume-padding.
est31 6y ago
> while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git. Can't those stages, tasks, etc. be specified in the CI specific config files of the repository? Specifying them via an UI seems horrible to me. At least Github actions is all file-specified (except for secrets).
- manigandham 6y ago
  It still requires conversion of config files and formats vs a script that is the same everywhere.
  - est31 6y ago
    Yes, that's a valid point, and definitely a disadvantage. I was referring to the point that it's not tracked in git.
InsaneOstrich 6y ago
Are you moving to Jenkins because of the recent Atlassian license changes?
- monkeybutton 6y ago
  Not entirely but I think it was the straw that broke the camel's back. Apparently our journey to the cloud will have to wait.
  - InsaneOstrich 6y ago
    I think there will still be a on premise version of Bamboo going forward, but all the license changes have made my company consider the possibility of moving from Bamboo to something else. That's kind of a shame, because Bamboo works really well for us.
merb 6y ago
btw. even gitlab does that with their autodevops, besides that they create gitlab-runner: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Build.gitlab-ci.yml#L17 https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/DAST-Default-Branch-Deploy.gitlab-ci.yml#L8 https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/src/bin/auto-deploy https://gitlab.com/gitlab-org/cluster-integration/auto-deplo... I found these fascinating, I mean they still have lots of things in their ci file, but basically the have tons of shell scripts that would work without their gitlab-runner. Not affiliated with gitlab I just tried to figure out how some of their stuff works to have the same k8s integration than their autodevops offers.

redis_mlc 6y ago

I call mine make.sh. Now get off my lawn!

monkeybutton 6y ago
Hey! I started with C projects and make scripts and I long for the simplicity of those days! Obtuse web front ends, bunches of build server pools segregated by random capabilities, job queues clogged by competing developer teams and on and on is no fun.
saurik 6y ago
I wouldn't want something called "make.sh" to install tooling on the computer, though, and that is an important step of CI stuff.
- aprdm 6y ago
  Run it in a docker container so that it does the same in your computer and in the CI worker. make prepare make build make test make release Working the same waylocally and in jenkins makes things very easy. What it does is up to the team but make prepare usually pulls some docker image and install dependencies, make build builds something inside the docker image, make test runs test inside it and make release publishes the docker img
  - laumars 6y ago
    Or use a CI/CD tool that natively supports Docker, like Concourse. Added bonus is that pipelines are defined in YAML rather than web GUI so you can version control the pipelines themselves and not just any build or test suites.
    - aprdm 6y ago
      Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). I have heard good things about Concourse, want to give it a try in the future!
      - laumars 6y ago
        > Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). There's several ways you can codify Jenkins pipelines, Groovy being just one of them. But ultimately it's secondary to the main design of Jenkins. I'm not taking anything away from Jenkins as a solution - it has been invaluable over the years. But the way we write, test and deploy software has changed since Jenkins rose in popularity and as such we need to rely on different workflows that utilise different tooling. While Jenkins can be used in that way, I'd sooner use something which was primarily designed to be configured via code and used docker by default rather than something that requires enforcement to follow those best practices. That doesn't necessarily mean Concourse, there's Travis, Circle CI, AWS CodeBuild and a bunch of others that all default to that kind of workflow too, but it does mean I'm unlikely to ever advocate Jenkins again in future jobs.
        aprdm 6y ago
        While you’re not wrong I do use jenkins inside docker and use ansible to configure it, it is a bit different than other more modern tools but works fine. I have yet to see other tools be as flexible (perforce , git, legacy tools, docker, 100s of workers across datacenters etc.)
        6y ago
  - redis_mlc 6y ago
    I think you missed the plot here. make.sh is instead of Docker, CI workers, fancy stuff, etc. :) It's for developers who care more about results than resume-padding.

est31 6y ago

> while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git. Can't those stages, tasks, etc. be specified in the CI specific config files of the repository? Specifying them via an UI seems horrible to me. At least Github actions is all file-specified (except for secrets).

manigandham 6y ago
It still requires conversion of config files and formats vs a script that is the same everywhere.
- est31 6y ago
  Yes, that's a valid point, and definitely a disadvantage. I was referring to the point that it's not tracked in git.

InsaneOstrich 6y ago

Are you moving to Jenkins because of the recent Atlassian license changes?

monkeybutton 6y ago
Not entirely but I think it was the straw that broke the camel's back. Apparently our journey to the cloud will have to wait.
- InsaneOstrich 6y ago
  I think there will still be a on premise version of Bamboo going forward, but all the license changes have made my company consider the possibility of moving from Bamboo to something else. That's kind of a shame, because Bamboo works really well for us.

merb 6y ago

btw. even gitlab does that with their autodevops, besides that they create gitlab-runner: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Build.gitlab-ci.yml#L17 https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/DAST-Default-Branch-Deploy.gitlab-ci.yml#L8 https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/src/bin/auto-deploy https://gitlab.com/gitlab-org/cluster-integration/auto-deplo... I found these fascinating, I mean they still have lots of things in their ci file, but basically the have tons of shell scripts that would work without their gitlab-runner. Not affiliated with gitlab I just tried to figure out how some of their stuff works to have the same k8s integration than their autodevops offers.