Skip to content

Convert Jently to a Gem? #34

@auxesis

Description

@auxesis

While we're talking about paths in #33, Jently is currently laid out like this:

lib/
├── core.rb
├── git.rb
├── github.rb
├── helpers
│   ├── config_file.rb
│   ├── logger.rb
│   ├── pull_requests_data.rb
│   └── repository.rb
└── jenkins.rb

1 directory, 8 files

I'm guessing this is because you're treating the Jently layout a bit like a Rails app?

If you were to transpose the layout to a RubyGem, it'd look like this:

lib/
└── jently
    ├── core.rb
    ├── git.rb
    ├── github.rb
    ├── helpers
    │   ├── config_file.rb
    │   ├── logger.rb
    │   ├── pull_requests_data.rb
    │   └── repository.rb
    └── jenkins.rb

2 directories, 8 files

This would make the requires look like this:

require 'jently/git'
require 'jently/core'
require 'jently/github'
require 'jently/jenkins'
require 'jently/helpers/logger'
require 'jently/helpers/repository'
require 'jently/helpers/config_file'
require 'jently/helpers/pull_requests_data'

I don't know what your thoughts are, but I think it would be super helpful to release Jently as a gem that reads in a config and can be run out of an init system like upstart or systemd.

This would mean:

  • Users would no longer need to clone the Jently repo, make a bunch of changes, and deploy it somewhere.
  • Users would get up and running with gem install jently + setup a config file + start the Jently daemon + done. 🎉
  • Users would be able to run multiple instances of Jently pointing at different repos without creating additional clones of Jently.
  • Users could deploy Jently with configuration management much more easily, and set up their own init scripts to wrap the Jently daemon.
  • Contributors wouldn't need to worry about accidentally committing and publicly pushing config.yaml.erb into their fork. 😰

The above reasons are informed from work I did on cucumber-nagios, which took a similar approach to what Jently does now. I've learnt from my experiences there and changed my opinion to building simple standalone tools that can be driven by standalone configuration files.

Let me know what you think. 🍰 I'd be happy to supply patches to make this happen, but only if you think it's a good idea.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions