/cutting_edge

Self-hosted dependency monitoring, including shiny badges! Currently supports Ruby, Rust, and Python projects.

Primary LanguageRubyGNU Affero General Public License v3.0AGPL-3.0

CuttingEdge -- Simple, self-hosted dependency monitoring

Ruby Build Coverage Status Cutting Edge Dependency Status Docker Pulls

CuttingEdge monitors the status of the dependencies of your projects and lets you know when any of them go out of date.

View the web front end of a live instance.

Features

  • Generates badge images that you can include in your projects' Readme, like the one above!
  • Can send you email when the status of a project's dependencies changes
  • Serves a simple info page detailing the status of each project
  • Supports the following languages:
  • Supports the following platforms:

Requirements

CuttingEdge is lightweight and easy to deploy:

  • No database required
  • Simple configuration through a projects.yml file
  • Requires relatively few resources (~120MB RAM), so...
  • It can even run on Heroku's free plan!

Installation

Using Docker

To run CuttingEdge on port 4567 on the host machine, with config.rb and projects.yml in the current working directory, simply:

  • docker pull dometto/cuttingedge:main
  • docker run -d --rm -p 4567:4567 -v $(pwd):/cutting_edge dometto/cuttingedge:main -c config.r

(Instead of using main, you can also use a release tag, e.g. dometto/cuttingedge:v0.2.1.)

Before running, define your repositories in projects.yml. You may also want to change some settings in config.rb.

Also see our example docker-compose file for an example of how to use CuttingEdge with Redis as a datastore via Docker.

Deploying on Heroku

CuttingEdge runs out of the box on Heroku, and is lightweight enough to function on the Heroku free plan. This repository already contains the Procfile needed for deployment.

Note: on Heroku, CuttingEdge uses heroku.config.rb instead of config.rb.

Steps:

  1. Clone/fork this repository, as it already contains some settings (in heroku.config.rb) relevant to Heroku
  2. Edit projects.yml and commit it to the repo.
  3. gem install bundler && bundle install
  4. git add Gemfile.lock && git commit -m "Commit Gemfile.lock for use on Heroku"
  5. heroku create my-cuttingedge
  6. heroku config:add HEROKU_APP_NAME=my-cuttingedge
  7. heroku addons:create heroku-redis:hobby-dev -a my-cuttingedge (using Redis is highly recommended on Heroku)
  8. git push heroku master
  9. Optional, if you want to receive email notifications:

You may also want to set some Heroku config variables, for instance to use authentication tokens in heroku.config.rb.

Note that Heroku switches off apps running on their free plan when they idle, so you may want to look at this.

As a gem

Simply:

$ gem install cutting_edge
$ cutting_edge

Or run from source:

$ git clone https://github.com/repotag/cutting_edge.git
$ cd cutting_edge
$ bundle install
$ bundle exec cutting_edge

Before running, define your repositories in projects.yml. You may also want to change some settings in config.rb.

Usage

When your instance of CuttingEdge is running, you can visit the landing page by pointing your browser to the root URL of the app. Locally, it is by default accessible at:

http://localhost:4567/

(Of course, you can also bind it to port 80 or 443 and make it accessible from the internet using the --port and --host arguments. Or you could place Apache or nginx in front of CuttingEdge.)

An instance on Heroku will be accessible through:

https://your-app-name.herokuapp.com/

projects.yml

projects.yml is the file in which you define which repositories you want CuttingEdge to monitor. Here's an example:

github:
  my_org:
    my_project:
      language: ruby

This will make CuttingEdge monitor the GitHub project my_org/my_project. You can add multiple repositories under the github: key, and also use the gitlab: key for repositories on gitlab.com out of the box. If you add self-hosted providers, you'll be able to define repositories using, for instance, my_gitea:.

The language: key can currently be set to ruby (default), rust, or python. Further supported keys:

  • auth_token: see here
  • hide: see here
  • locations: use to change the default path to dependency definition files. For instance, for a Ruby project, CuttingEdge will by default try to monitor Gemfile and my_project.gemspec. You can override this with language: [Gemfile, alternative/file.gemspec]
  • branch: use a different branch than the default main
  • email:
    • disable email notifications for a single project by setting this to false
    • use a non-default address delivery address for this project by setting this to e.g. myproject@mydependencymonitoring.com

Note: by default CuttingEdge will use projects.yml in the working directory. You may optionally specify a different path by running cutting_edge path/to/my_projects.yml.

Instead of projects.yml, you can also define projects in config.rb.

config.rb

To configure CuttingEdge specific settings in config.rb, you can run cutting_edge with the --config switch (you can optionally specify an alternative location for the config file). Always make sure you are defining your settings from within the CuttingEdge module. For instance:

module CuttingEdge
  REFRESH_SCHEDULE = '2h'
end

The sample config.rb contains some examples of constants that you may wish to configure. Here are some descriptions of what the less obvious ones achieve:

  • SECRET_TOKEN: set a global secret token for administrative purposes. This token is used to configure hooks, and to list hidden projects.
  • SERVER_URL: the link to the app that should be displayed, for instance in emails. Defaults to "http://#{SERVER_HOST}"
  • MAIL_TEMPLATE: override the ERB template used to render emails. See mail.html.erb for an example on which variables you can use within the template.

Email Notifications

CuttingEdge can send email notifications whenever a change in the dependency status of a monitored project is detected. This is disabled by default. Enable it in config.rb:

module CuttingEdge
  MAIL_TO = 'mydeps@mymail.com'  # Default address to send email to. If set to false (=default!), don't send any emails except for repositories that have their 'email:' attribute set in projects.yml
  MAIL_FROM = "cutting_edge@my_server.com" # From Address used for sending emails.
end

By default, the app wil try to use an SMTP server on localhost:25. Change these settings in your config.rb by calling Mail.defaults:

# This should be outside the module CuttingEdge
Mail.defaults do
  delivery_method :smtp, address: "localhost", port: 1025
end

See the mail gem for more information.

You can switch off email notifications for a single project by setting its email: key to false in projects.yml. Alternatively, you can set the email: key for a single project to a different address than the default MAIL_TO.

Adding self-hosted repository servers

You can monitor projects on your own self-hosted Gitlab or Gitea instances. To do so, you need to tell CuttingEdge about your server by editing config.rb as follows:

module CuttingEdge
    require './lib/cutting_edge/repo.rb'
    define_gitlab_server('mygitlab', 'https://mygitlab.com')
    define_gitea_server('mygitea', 'https://mygitea.com')
end

This will allow you to use the mygitlab: and mygitea: keys in projects.yml, for instance like so:

mygitlab:
  myorg:
    project-name:
      lang: rust
mygitea:
  myorg2:
    project-name2:
      lang: python

Don't forget to run CuttingEdge with the --config option!

Authorization and private repositories

If you want to monitor dependencies in a private (e.g. GitHub or Gitlab) project, you can instruct CuttingEdge to use an API token for accessing the dependency files. In projects.yml:

github:
   secret-org:
     secret-repo:
       auth_token: 'mysecrettoken'

For info on generating API tokens, see:

Defining repositories in config.rb

If you don't want to expose information about a project in (such as an API token!) projects.yml (which may be publically accessible on the internet), you can instead define your project repository programatically in config.rb. This will allow you to define repositories with secret parameters by (for instance) utilising environment variables:

module CuttingEdge
    require './lib/cutting_edge/repo.rb'
    REPOSITORIES = {
      "gitlab/#{ENV['SECRET_REPO1_ORG']}/#{ENV['SECRET_REPO1_NAME']}" => GitlabRepository.new(org: ENV['SECRET_REPO1_ORG'], name: ENV['SECRET_REPO1_NAME'], auth_token: ENV['SECRET_REPO1_AUTH_TOKEN'], hide: ENV['SECRET_REPO1_HIDE_TOKEN'], email: 'myemail@mydomain.org')
    }
end

This approach is especially useful on Heroku, where you can use Heroku config variables.

NB: When adding repositories in config.rb, you must explicitly set the email attribute (or else email will be considered disabled for the repo).

Hide Repositories

You may want the name and dependency monitoring information for private repositories (see above) not to be visible on the internet. To achieve this, you can use hide: token in projects.yml:

github:
   secret-org:
     secret-repo:
       auth_token: 'mysecrettoken'
       hide: 'myhiddenrepo'

...or again, you can do so in config.rb following the method explained above:

GitlabRepository.new(org: ENV['SECRET_REPO1_ORG'], name: ENV['SECRET_REPO1_NAME'], auth_token: ENV['SECRET_REPO1_AUTH_TOKEN'], hide: ENV['SECRET_REPO1_HIDE_TOKEN'])
end

Setting the hide key to a token of your choice will ensure that:

  1. your hidden repo is not listed in the web frontend.
  • to list all hidden repositories, you can enter your CuttingEdge::SECRET_TOKEN after clicking the "List hidden repositories" on the landing page.
  • NB: this is your global administrator token, not the particular token used to hide a particular project.
  1. the /info route and SVG image for your hidden repo are not accessible without the repo-specific token you have set via hide:

When you go to the /info route for your hidden repo (by first entering your administrator token, then clicking on the SVG for the project), you can click the "Embed" button and thereby acquire a link to the SVG dependency status image that contains the hide: token. You can thus use this link on a private repository, without giving collaborators on that project access to information about your other hidden repositories!

Refreshing dependency status through git hooks

CuttingEdge by default checks whether the status of your dependencies has changed once every hour. However, if you wish, you can also setup hooks so that dependency status is checked (for instance) whenever you make a commit to your project.

For this purpose, CuttingEdge provides the following route:

http://mycuttingedge.com/github/org/myproject/refresh?token=mysecrettoken

An HTTP POST request to that route will cause the dependencies for that project to refresh. This requires you to define a secret token in config.rb, so that third parties cannot trigger refreshes. In config.rb:

module CuttingEdge
  CuttingEdge::SECRET_TOKEN = 'mysecrettoken' # Note: this token is used to refresh all the projects on your CuttingEdge instance
end

Using this route you can, for instance, set up a GitHub Action (or equivalent for other providers). Of course, this requires defining the secret token as (for instance) a GitHub Secret.

You can test the route like this:

curl -d 'token=mysecrettoken' http://mycuttingedge.com/github/org/myproject/refresh

Using Redis and other data stores

CuttingEdge does not require persistence, as the data it uses (which dependencies does a project have, and are they up to date?) is refreshed periodically anyway. By default, this information is stored in memory. However, if you would like to store data in a different kind of data store (for instance Redis) that can be trivially accomplished. This may further decrease the amount of RAM CuttingEdge requires, and possibly improve performance.

CuttingEdge uses Moneta as an abstraction layer for its data store, so to change the data store can just do the following in config.rb:

module CuttingEdge
  STORE = Moneta.new(:Redis)
end

See the Moneta instructions.

Note that Heroku offers a free Redis Add-on.

Contributing

See here.

License

This work is licensed under the terms of the GNU Affero GPLv3.0. Copyright Dawa Ometto and Bart Kamphorst, 2020.