This Ruby application can be used to notify Slack channels of the fuelling state of a corporation's Upwell structures. A structure's fuelling state is one of the following:

• unknown
• good
• warning
• danger

The application remembers the previous state of each structure so that it can be run often but only report when a structure's state changes.

The application takes its configuration from a file named on the command line, or config.yaml by default. This file contains various secrets, so I haven't included the one I'm using in the repository. Instead, example-config.yaml can be used as a template.

You need to have registered a third-party application with CCP at https://developers.eveonline.com; this will give you the client_id and client_secret values to put in the configuration. Your application's registration should include at least the following scopes:

• esi-corporations.read_structures.v1

Once you have a registered application, you need to manually use the EVE SSO to log in as a character from the target corporation with the "Station Manager" role, and request those same scopes. If you don't know how to do this, CCP have a step-by-step article covering the process.

The resulting refresh token goes into the refresh_token configuration item.

If present, the systems configuration item is a list of solar system names; the application will only report on structures anchored in these systems. If systems is absent, structures in all systems will be included.

The configuration items danger_days (default 7) and warning_days (default 14) determine how to translate the time left before fuel runs out into a fuelling state:

• If the time left is less than or equal to danger_days, the state will be danger.

• If the time left is greater than danger_days but less than or equal to warning_days, the state will be warning.

• If the time left is greater than warning_days, the state will be good.

If you don't want to use the warning state, just set danger_days and warning_days to the same value. Structures will then go straight from good to danger.

The application tracks the previous fuelling state of structures so that it can notify the Slack channel only when the state changes. This state is held by default in the file state.yaml, but if you'd like to put the state file somewhere else (for example so that you can mount it into a Docker container) then its location is taken from the statefile configuration item.

If any of the notifications are for a danger state, the message will be an @channel ping.

If there are some state changes to notify (within the given solar systems) then Slack's "incoming webhooks" facility is used to make a nice notification with an attachment state change. The details are nested under a slack configuration item:

• The URL you get from your webhook configuration goes in webhook_url

• channel can be a public or private channel prefixed by #, e.g., '#fuel-panics'. It can also be a user name prefixed by @.

Set up as follows:

$ bundle install --path vendor

Execute like this:

$ bundle exec ruby fuelbot.rb

Over in Slack, you might see something like this:

The application is designed to be relatively friendly to being deployed as a Docker image and executed within a container. The following files are included to give some ideas as to how to go about that:

• .dockerignore
• docker-build
• docker-run
• Dockerfile

The assumption is that you have a basic level of understanding about how Docker works; let me know in a GitHub issue if you have that but something is still unclear.