It is being built in house at BVN DH as a way to pull together all our data sources.
Currently it's main focus is on collecting data from disparate historical sources (all the spreadsheets that have been made in the past as problem hacks). Most of this data is incomplete and dirty, so the other thing that it does is allow people who have knowledge to go and edit the data themselves.
It is written for architecture practices, but might be applicable/portable to other fields.
The name comes from another group of trackers.
We're probably not ready for anyone to get involved in a big way as we're changing too much stuff, but if there are any features that you would like to see, or bugs that you think we should fix, then feel free to open an issue.
- Make a new branch called [issue number]-[Short_description_of_issue] (underscore separated)
- Move issue into "in progress" on Waffle
- Work on issue
- Make pull request through GH website
- Move issue into "under review" column in Waffle
- Test/discuss/etc. code
- Merge pull request and delete branch
- Move issue into "in dev" column in Waffle
- Deploy if you feel like it
ShadowWolf is 5 main components which currently live inside docker containers.
- A MongoDB database
- An Angular front end
- A rails back end
- A small sinatra app for interfacing with OpenAsset
- A small flask app for interfacing with Epicor
To install the environment for the first time:
mkdir Projects
cd Projects
git clone https://github.com/notionparallax/ShadowWolf.git
cd ShadowWolf
Make sure Vagrant and Virtualbox are installed, then:
vagrant up
vagrant ssh
./docker-util build dev
Make sure docker is installed and the daemon is running. Additionally make sure docker can run without the sudo command have docker-compose also installed. When in doubt, use the same version of docker-compose described in the Vagrantfile provision script. Then:
./docker-util build dev
To save you from having to start these independently you can just run (inside the vagrant machine):
cd Projects/ShadowWolf/
./docker-util dev client
Which starts up the five containers in daemon mode. You can then go to http://localhost:9000/#/people to see everything in action. Note that logins wont work unless you are are the BVN network.
The DB is empty when you start it, so to fill it with sample data:
./docker-util dev factories
docker ps
- list all active docker containersdocker kill
- kills a docker container./docker-util console
- opens a rails console connected to the Mongo database./docker-util run [bash]
- this takes a command and runs it inside the dev environment container. This lacks port forwarding and linking (e.g. no access to the DB). So it is useful for testing specific things in the environment.
./docker-util
is a very light wrapper around docker. If you want to do something that ./docker-util
doesn't support then just read the docker docs and get on with it!
Note: docker-util is run from your local machine, it then does the work of ssh
ing into the container for you. E.g.
$ ~/Projects/ShadowWolf$ ./docker-util prod console
docker-util can:
- build images for local use
- run local servers
- connect a console to local rails server (to create fake data)
- observe logs of local servers
- build images for production use
- deploy images to production
If the docker images do not exist on your machine: (only needed once, takes the longest)
./docker-util install
To get the dev server running locally: (only needed once per development session or on change to show files)
./docker-util dev client
To populate the local database with test users: (only needed once per dev session)
./docker-util dev console
# The following commands are in the ruby console
p = FactoryGirl.create_list( :person, 10 ).first
p.current_condition.name = 'Active' # make sure it's visible
p.employee.login = 'bdoherty' # make sure it can log in via ActiveDirectory
p.save
To re-run the build scripts after modifying any of the show pages: (as mentioned above, only when show files change)
./docker-util dev client # same as above
yeah, apparently it works already. It may sometimes take a moment or two past when the docker-util script exists. So...
To look inside the local server and see when it finishes building: (only when curious about ongoings of container)
docker logs -f sw-client # the f is for follow
To build an image for deployment (asks for sudo password): (only for predeployment)
./docker-util build client
To deploy an image (asks for BVN IP and server login): (only for deployment)
./docker-util deploy client
So to do a full deployment you can:
./docker-util build client && ./docker-util build server && ./docker-util deploy client && ./docker-util deploy server
If you add the server IP to your .bashrc
file then you can put a password in at the beginning and then leave it while you have a cup of tea!
You can always look inside the docker-util file to see how a command works under the hood. The script is just a handful of nested cases to match against arguments. Each matched command is usually a call to docker who's commands a documented with
docker help
docker [command] --help
Although if things work then you should theoretically be able to do without.
If you need to edit the production database you can use:
./docker-util dev console
and then use ruby commands. Some examples are shown in ShadowWolf / Helper scripts / DB terminal scripts / photo.rb
The Mongo back end uses the MongoidModelMaker gem to build out the data models.
Rails really only works to control the database, flicking chunks of JSON at the angular client.