Set up a staging/testing space for the dashboards (Discovery dashboards beta)
Closed, ResolvedPublic4 Story Points


We need a second dashboard instance on a new machine that we can use as a test/staging platform. One likely side-effect of this is that we rework the vagrant setup so that it only polls for a new version when it's told to, rather than every N minutes - which honestly is probably a far better approach.

Ironholds created this task.Sep 9 2015, 5:44 PM
Ironholds updated the task description. (Show Details)
Ironholds raised the priority of this task from to Needs Triage.
Ironholds added a project: Discovery.
Ironholds added a subscriber: Ironholds.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 9 2015, 5:44 PM
Ironholds moved this task from Needs triage to Analysis on the Discovery board.Sep 9 2015, 6:20 PM
Deskana triaged this task as Normal priority.Sep 10 2015, 8:13 PM
Deskana added a subscriber: Deskana.
Deskana renamed this task from Set up a staging/testing space for the dashboards to Set up a staging/testing space for the dashboards (Discovery dashboards beta).Oct 15 2015, 8:20 PM
Deskana set Security to None.
Ironholds edited a custom field.Oct 21 2015, 5:59 PM
mpopov added a subscriber: mpopov.Oct 22 2015, 10:17 PM

When @Ironholds has an opportunity, I would like him to show me how to set up forwarding and whatnot so we have (for example) pointing somewhere.

Let's chat today and work on this.

Okay, now we have a

(Thanks to @Ironholds for showing me how to spin up an instance and make a web proxy!)

Awaiting a +2 on a tiny patch ( that I'll use for testing out a "keep the dashboards always up-to-date" script.

Alright. I've got the following script scheduled to run every 5 minutes (as in my home directory on that instance. It appears to work as intended (have the latest versions of the dashboards).

cd /srv/dashboards

# We need to check if the dashboards repo has been
# updated (e.g. packages added to Only
# then can we pull latest versions of dashboards.

# Bring remote references up to date:
git fetch origin

# Check if there are remote changes that
# need to be merged in:
MERGES=$(git log HEAD..origin/master --oneline)
if [ ! -z "$MERGES" ]; then
  CHANGES=$(git diff --shortstat)
  if [ ! -z "$CHANGES" ]; then
    # Clean out uncommitted references to dashboards:
    git submodule update --init
    # ^ avoids conflicts when pulling origin/master
  # Bring this repo up-to-date:
  git pull origin master
  # Do some minor doctoring:
  sed -i 's/\(Discovery Dashboards\)/\1 (Beta)/g' shiny-server/index.html 
  # Re-provision the vagrant container:

# Pull latest version of each dashboard:
git submodule foreach git pull origin master

# Check if newer ver's of dashboards were downloaded...
# ...but first let's ensure we don't get an error:
if [ ! -e '/home/bearloga/submodules_status.txt' ]; then
  touch /home/bearloga/submodules_status.txt
# ...okay, let's actually do the check now:
OLDSTATUS=`cat /home/bearloga/submodules_status.txt`
NEWSTATUS=$(git submodule status)
if [ "$OLDSTATUS" != "$NEWSTATUS" ]; then
  # Restart because different (newer?) dashboards were dl'd:
  service shiny-server restart
  # Save hashes for next checkup:
  git submodule status > /home/bearloga/submodules_status.txt

Oliver and I discussed adding version info on the index page ( and I think the best (read: easiest) way to do that would be something similar to where I add "(Beta)" to the header. We can include empty space for it in index.html and then use sed to inject git commit info into it for the dashboards. (This beats installing and configuring apache2/php5 on the instance, but that's just my $.02)

Deskana closed this task as Resolved.Dec 24 2015, 1:33 AM