icebreakerone/open-energy-status

open-energy-status

See the live API status dashboard.

open-energy-status's Issues

Refine our GitHub workflow

Before merging code to the main branch, what should we do? We probably agree that tests should pass and that code should undergo some kind of review.

When should we squash commits as opposed to keeping them separate? When should we use multi-parent merge commits and when should we keep a flat history? What should merge commits look like? When do we delete branches? How do we name branches? What do good/bad commit messages look like?

I have opinions on some of these matters and I expect you do too. Once we reach a rough consensus, we can configure GitHub to support our workflow.

Reconsider our choice of operating system

In the rough deployment ideas document, we state that environments will run some kind of Unix with a good packaging system. However, a205e46 installs npm using curl | bash as the Debian version is too old. Does this suggest we want to use a different operating system with more recent packages?

Make proper API calls to Raidiam

Currently, our Raidiam tests make HTTP calls but do not use Raidiam's API in any significant way. We should define what we consider a reasonable check (can we get away with what we have now?), then write the code to make it happen.

Rethink our use of Netlify

Currently we publish two sites to Netlify using API secrets. TomH has created an account with his IB1 email address, but it's not shared. Also, the secrets he has are per user, not per site, and he wonders if this means any of his accounts' secret keys can publish to any of his sites, which isn't what he intended to do. If we continue to use Netlify, we'll want to think about how we manage our account(s) and how we compartmentalise/secure them.

Run actions locally as well as in GitHub

We currently use GitHub actions to run tasks. We will want to run tasks locally on development environments as well as in GitHub itself, without duplicating the definition of tasks. My first though was to move the logic to shell scripts, Makefiles or similar, but that would mean losing the power of reusable actions such as snok/[email protected]. I've since discovered act which looks like it might allow us to run actions within a Docker container.

Update README

Add a description of the project and how to use it to the README file. It would make sense to do it after #13 has been closed.

PEP8 compliance pass

PEP8 is the python standard coding style, worth checking that we're compliant with it.

GitHub / Slack Integration

We might create a new Slack channel (channels?) that receives event (commits, issue open/comment/close) notifications automatically from our GitHub repository.

Automatically run API endpoint checks periodically

Currently we call the API endpoints on each commit and only when we commit. Once we have completed #8 we can run call the endpoints to check their status periodically regardless of when we commit.

Install Python dependencies from repo's poetry.lock

Currently, our image installs Python dependencies from the static poetry.lock that was added to the Dockerfile. This, however, will cause problems as soon as we start adding Python dependencies to the repo. Instead, we should only install the system dependencies in the image, skip adding poetry.lock to the Dockerfile and point to the repo's poetry.lock.

Generate development environments

For now, we run and test our code in GitHub actions: we have coped without development environments. We will quickly outgrow this approach. Once we have completed #8, we can make a separate environment build step that uploads an image to DockerHub that we can download and run ourselves.

We might be able to separate out when the test phase runs from when the environment builds happen based on some logic within GitHub actions, but I don't know enough about this yet.

• create a DockerHub account
• write Dockerfile
• write shell script with tests
• publish the image on DockerHub
• ammend GitHub actions workflow

Make tests fail more helpfully

When tests fail, they should output helpful messages. Currently when our tests fail they don't provide a useful description of what went wrong. We can provoke failures by temporarily changing test expectations. I suspect we can use assertions for this.

HTML Status Page

Currently we have two status badges that show whether we can call each HTTP endpoint. Once we have completed #9, we will want to produce a public HTML view showing the results of recent checks.

This will involve:

• Writing a new script to generate HTML output
• Storing the HTML output somewhere (netlify, GitHub pages, S3 bucket)
• Pointing a DNS record at the HTML output

We might want to use a more sophisticated dashboard/status tool. I forget the name of the one that @frank-ib1 mentioned earlier today.

Separate actions for environment building and calling API endpoints

Currently our GitHub actions build an environment and call API endpoints. We should separate these so we can build environments on each commit to the repository and run API endpoint checks periodically.

We should refactor our actions to include reused steps instead of copying them between different files.