8
p32929
1y

Recently I've been learning Rust & I wanted to make something useful. So, I made a Jenkins alternative. It is currently being used in our company, which feels good. So far its working great.
& I wouldn't necessaily say I'm "proud" of it, but rather I'm "thankful" that I was able to do that. Cause, Rust is pretty popular for its steep learning curve & thinking of making something like Jenkins with Rust before actually learning Rust takes a lot of courage

Comments
  • 2
    I'm ... A bit shocked and in disbelief...

    You wrote an *entire* CI like Jenkins by your own in rust Oo?

    I don't want to diminish your work, but this sounds unbelievable.
  • 2
    @IntrusionCM to be honest, even I couldn't believe myself when it actually worked & I still can't believe that my colleages are using it without any issues so far.

    let me ask you this, cause when I was making it, I wasn't really thinking of it in terms of a CI/CD tool but I just wanted to make something thats easier to setup than jenkins. so, all it does is:
    when there's a change in certain branch of a repository in github/gitlab/etc, it grabs the code, runs necessary commands to run the code of the repo in production mode.
    is there more to it in a CI tool?
  • 3
    I can totally imagine this. CI/CD tools are very large and complex because they're supposed to adapt to every company's unique production setup and development workflow. They're all similar but different in the subtlest of details, so everything needs to be configurable. If you're developing one for *your company* then it's only slightly too large to implement in Bash.
  • 1
    @p32929

    Depends on point of view.

    What you described is a task runner imho - which is a core part of a CI.

    Check out repository, run task.

    A CI usually goes deeper than that - though its feature set depends entirely on the product.

    What's added to the the task runner is usually the bunch of environment handling, isolation of tasks (e.g. containerization), parallelization (queue of jobs), grouping (global / project / task e.g.), inheritance of environment (e.g. project can inherit from global), permissions and authentication, ...

    That's why I was in disbelief, cause a "full" CI / CD is really a lot of work and bleep (e.g. sane environment handling and isolation of host vs task environment can make a WHOLE lot of pain).

    A task runner is never the less no small feat ;)

    Written myself a few ones, especially when you need to deal with input vs output for interactive programs, it becomes ... Interesting. XD
  • 0
    @lorentz Thanks for the explanation. so, adaptability is one the main purposes of a CI/CD tool, right?
    if thats the case then my app is pretty adaptable without any plugins. So far we have tried it for Nodejs backend, Reactjs frontend & some dockerized python backends. it worked for these without any issues so far
  • 0
    @IntrusionCM I see. so, should I not call it "Jenkins alternative" anymore? cause, whatever we used to do with jenkins, its doing all of it okay so far.
  • 1
    @p32929 You can call it whatever you want, it just sounded (in my own opinion) just bigger than it was.

    Which made me kinda curious cause an complete CI / CD in Rust would be interesting for obvious reasons.

    :)
  • 1
    @IntrusionCM I see. Its just that I'm not very familiar with the CI/CD tools other than Jenkins. To be honest, I dont know much about CI/CD either. All we did using jenkins was auto-deploying the code from github to the VPS. not sure what else can Jenkins do. Pretty sure it is a very powerful tool.
Add Comment