avdgaag / wally Goto Github PK

7.0 2.0 4.0 306 KB

Status wall application in Elixir, Phoenix and React

Elixir 47.23% JavaScript 22.14% CSS 14.83% Shell 14.17% HTML 1.63%

wally's Introduction

Wally

A toy software status wall application built with Elixir, Phoenix and React. Use it to display your CI build status and latest project activity on a big screen in the office.

Quite a work in progress. Note that this project is absurdly over-engineered, but it is a much a playground as it is an application.

Installation

This project requires both a working installation of Elixir and Node.js (with NPM installed). It uses Redis as its database.

To start your new Phoenix application:

Install dependencies with mix deps.get and then npm install.
Start your Redis database with redis-server.
Start Phoenix endpoint with mix phoenix.server.

Now you can visit localhost:4000 from your browser.

Testing

You can run this project's tests in two parts:

Test Elixir back-end code with mix test.
Test Javascript front-end code with npm test.
As a shortcut, test both using bin/test.

Do make sure you have Redis running the background.

Overview

This application renders a list of projects and their status on the client side, while receiving web hooks from external services on the server side. Using websockets, the client is updated immediately.

Currently the only implemented web hooks are:

a Heroku deployment notification;
a Codeship build status notification;
a Github commit status API notification.

Deploy to Heroku

To deploy this application to a new Heroku application, use this button:

wally's People

Contributors

Stargazers

Watchers

Forkers

florish acpk colaborati warantesbr

wally's Issues

Replace Postgres with Redis

It seems that Redis might be good fit for this data model, since we're mostly updating lots of keys and values. Postgres is fine, but Redis is cool and available (in beta) as standard feature on Heroku, which makes setup easy enough.

The main selling point for using Redis would be a much simpler data model, because we no longer need to mangle queries and JSON.

Authentication

Implement an authentication system so only selected services can post to Wally or access its wall (and subscribe to the websocket).

The idea is to track keys in the app and make them part of the URLs you give third parties to post to. That works for hooks, but not for the wall and websockets. This should use a regular browser-based authentication session.

Create CRUD interface for API keys (#26)
Authenticate key on incoming requests
Add regular cookie-based authentication, maybe using HTTP auth, for web interface and websocket.

Inspect projects

Add a Mix task to inspect a project, so you can get the token to add more integrations.

Create a single test command

Create a single command to run both mix test and npm test.

Time ago

Shows a relative date (e.g. "3 days ago")

Acceptance tests

Create some full-stack tests that fire up a browser and see the wall change when events come in.

Application deployment

This is currently implemented for Heroku, but we might want to check if we want to support multiple applications per project.

Open support tickets

Shared calendar events

This might require polling an external calendar, including all required authentication, rather than receiving web hooks — which makes this rather more complex than regular plugins. But maybe notifications can work, too.

Omit tokens from front-end code

The React app holds a bunch of data, including project API tokens. It does not need to have that information. Filter it out.

Counter

Shows a simple counter (numeric value)

Remove expired events from front-end

Since events may be removed from the database, we need to let the front-end know they can be removed. Otherwise, the list of events will keep growing forever.

Add expiration to Redis event keys

We don’t need to keep data around forever. Event keys can expire after a while (30 days?) so we track only a limited set of events. The only problem is we also need to update other keys that contain references to those expired keys. We can dot that by observing expirations from Redis and let the application update related keys (the global list of event IDs and project-specific lists of IDs).

Github build state

We only take into account passing or erroring builds. We also get events for pending builds. We can show a yellow indicator then.

CI build status

Accept updates about CI build status. This is currently implemented for Codeship, but maybe this can be adapted to support other services (at the very least, it should not be hard to do so). Also, check if we can support three states: passed, failed and running.

Display latest deployment per project

Probably a comment on the line: about x hours ago. Or just the number of deployments this day/week/month.

Manage projects

A GUI to manage projects in the system, including their external identification details (a JSON blob).

Logentries webhooks

We can support a range of application-specific notifications as well as Heroku platform error monitoring by implementing hooks at the log level. This feature should support sending custom "events" to Wally (so that Heroku platform errors can be differentiated from new user signups, for example).

Passed
Failed
Pending