circleci-public/buildinfo-extension

BuildInfo Extension

This is a very early preview of a browser extension that adds some fun new features to the CircleCI experience. Built with React/Redux.

Development - Chrome

Dependencies

Requires node and yarn installed.

Setup

• clone the repo

• install everything

  cd buildinfo-extension && yarn install

• build the unpacked extension, or use development watcher

  yarn run webpack

  yarn run watch

• load the unpacked extension in chrome. The unpacked extension will be located at the root of the project in a folder called dist.

• give yourself a pat on the back. Then extension should be running when you visit a CircleCI domain

Extra credit

When you make any changes to the code while using yarn run watch the unpacked extension will be rebuilt automatically. This does not reload it in the browser unfortunately. On the extensions page you have to click reload on the extension, and then refresh the browser. Lame right? To ease that pain a bit you can install this other chrome extension that will reload unpacked extensions when you click it. So at least you don't have to navigate to the extensions page. Make a code change, click the extension reloader, refresh the page, view your changes.

buildinfo-extension's Issues

Configuration Suggestions

This is probably a far future feature but Tom suggested to write it down now. When viewing a build show "configuration suggestions" for things we commonly encounter in support. The goal is to reduce incoming tickets by bringing configuration improvements to the user's attention. This also helps guide the user towards an improved experience on the platform.

For instance, we know that jest tests spawn a worker for each available core and toolings in the environment report 32 cores available. This causes lots of problems since they're usually limited to 2 cores. Often times we have to advise users to add --maxWorkers=N to their configuration files based on the available cores for their job. By scanning their config looking for jest we could advise the user to add this before it becomes an ongoing issue for them and a ticket for us.

Other potential suggestions:

• advising to use CircleCI pre-build images in place of official images for languages and services
• making sure to use set -e when they're running a .sh script to avoid suppressing errors
• using sudo for run steps when using a circleci docker image
• detect non-posix compliant syntax in cron scheduling workflows
• set environment variables for memory management when we detect they're using some java toolings (such as gradle)
• detect usage of depreciated config syntax and suggest the updated syntax

For now, this issue is probably a good place to dump suggestion ideas.

Move Redux to background.js

Right now everything is stored on the 'frontend'. this is really bad for several reasons. The worst being when you open a new tab the extension "forgets" everything and acts as a fresh instance. By moving redux to the 'backend', and connecting the 'frontend' to the background store, new tabs will always pick up the current state of the extension.

There are some libraries designed to alleviate the complexities of separating redux from the frontend logic. Though it needs to be considered that I've set up the app so that it should be trivial to build firefox/edge versions with a single webpack config. Using libraries targeted for chrome/firefox specifically could spoil the cross-build goal. Though they could be good inspiration for rolling a custom solution.

reading

https://robots.thoughtbot.com/redux-for-chrome-extensions

examples/libraries

https://github.com/Dharmoslap/redux-chrome-extension
https://github.com/jhen0409/react-chrome-extension-boilerplate
https://github.com/zalmoxisus/browser-redux-sync
https://github.com/zalmoxisus/browser-redux-bg

Filter Meta view rows

The Meta view has lots of rows of data right now. Probably only need to reference a couple of them when troubleshooting. I think having a filter input at the top that filters the displayed rows would be cool. Kinda like how you can search for chrome settings.

Normalize build data in Redux

At the moment bi-ext handles build data in a very inefficient way. There's an array that stores the API response of the latest 30 builds from a project, but that data is only used to identify recent changes to config files. Anytime we edit one of the build number input fields it makes a new request to get that build data. Even if we already have that data in the array, or we have previously requested that data before. Not good. If we've requested build data once it should stay available in the app state, and be reused.

What I think needs to be done is create a general build store for all build data, and have this store normalized. The tricky part is how to organize it so that collisions don't occur across project builds. It would be nice to access builds based on their build number as a key, but it would also be nice to have all build data in a single store regardless of the project it was pulled from. That would make it easier to filter or transform the data for other purposes. Will have to figure out a solution here.