Buildbot firstrun, Web UI does not show ForceScheduler in waterfall view

Question

The First Run tutorial is all well and good. Everything installs correctly and the WebUI is displayed. However, the runtests cannot be run. The tutorial directs the student to the Waterfall view to see the runtests builder. runtests does not appear anywhere on the Waterfall page. To force the run you go to the builder page and click the force button. Unfortunately I do not have that button available in my WebUI. I do see one line in the logs that's troubling. But I don't know what to make of it:

2017-07-10 00:09:15+0000 [Broker,0,127.0.0.1] Worker example-worker attached to runtests
2017-07-10 00:09:37+0000 [-] dropping connection to peer tcp4:127.0.0.1:48686 with abort=False

... because the worker attached from IPv4Address at (TCP, '127.0.0.1', 39436). So I'm not sure which connection was dropped.

Below is the info that got sent by buildbotNetUsageData. I'm running this on AWS in an ec2 instance. Only ports I have open are 80, 443, 22, 9989. The worker is on the same machine as the master. I'm using Nginx to proxy_pass localhost:8010 to public port 80. Using the default Python on Ubuntu 16.04 server.

My first instinct is that I'm overlooking something obvious. This is my first experience with buildbot. However I'm not sure how to debug this. I'm getting no errors and no failures anywhere.

The Web UI is also doing some funky stuff. The only way example-worker shows up in the /#/workers page is if I'm viewing the /#/builders page first. It won't show up if I'm coming from say /#/ (home) or /#/waterfall. I have to go to /#/builders first, then go to /#/workers. That's the only way example-worker shows up there.

I've been hacking at this for a little while. I've tried using ubuntu 14.04, but had trouble installing buildbot. Same with REHL. I'm doing this via ansible, which I'm also learning. So I've spent quite a bit of time tweaking my playbook and roles.

Question:

My question is this. How do I get around this and force the runtests builder?

Not an answer:

This question is not an answer because I do not see the force button.

buildbotNetUsageData:

{
  "versions": {
"Python": "3.5.2",
"Twisted": "17.5.0",
"Buildbot": "0.9.9.post2"
  },
  "platform": {
"system": "Linux",
"version": "#22-Ubuntu SMP Fri Mar",
"python_implementation": "CPython",
"machine": "x86_64",
"processor": "x86_64",
"platform": "Linux-4.4.0-1013-aws-x86_64-with-Ubuntu-16.04-xenial",
"distro": "ubuntu:16.04"
  },
  "mq": "simple",
  "db": "sqlite",
  "www_plugins": [
"waterfall_view",
"console_view"
  ],
  "plugins": {
"buildbot/changes/gitpoller/GitPoller": 1,
"buildbot/schedulers/basic/SingleBranchScheduler": 1,
"buildbot/config/BuilderConfig": 1,
"buildbot/schedulers/forcesched/ForceScheduler": 1,
"buildbot/worker/base/Worker": 1,
"buildbot/steps/shell/ShellCommand": 1,
"buildbot/steps/source/git/Git": 1
  },
  "installid": "<some long number>"
}

EDIT #1: This is the default master.cfg to which I've made no edits:

# -*- python -*-
# ex: set filetype=python:

from buildbot.plugins import *

# This is a sample buildmaster config file. It must be installed as
# 'master.cfg' in your buildmaster's base directory.

# This is the dictionary that the buildmaster pays attention to. We also use
# a shorter alias to save typing.
c = BuildmasterConfig = {}

####### WORKERS

# The 'workers' list defines the set of recognized workers. Each element is
# a Worker object, specifying a unique worker name and password.  The same
# worker name and password must be configured on the worker.
c['workers'] = [worker.Worker("example-worker", "pass")]

# 'protocols' contains information about protocols which master will use for
# communicating with workers. You must define at least 'port' option that workers
# could connect to your master with this protocol.
# 'port' must match the value configured into the workers (with their
# --master option)
c['protocols'] = {'pb': {'port': 9989}}

####### CHANGESOURCES

# the 'change_source' setting tells the buildmaster how it should find out
# about source code changes.  Here we point to the buildbot clone of pyflakes.

c['change_source'] = []
c['change_source'].append(changes.GitPoller(
        'git://github.com/buildbot/pyflakes.git',
        workdir='gitpoller-workdir', branch='master',
        pollinterval=300))

####### SCHEDULERS

# Configure the Schedulers, which decide how to react to incoming changes.  In this
# case, just kick off a 'runtests' build

c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
                            name="all",
                            change_filter=util.ChangeFilter(branch='master'),
                            treeStableTimer=None,
                            builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
                            name="force",
                            builderNames=["runtests"]))

####### BUILDERS

# The 'builders' list defines the Builders, which tell Buildbot how to perform a build:
# what steps, and which workers can execute them.  Note that any particular build will
# only take place on one worker.

factory = util.BuildFactory()
# check out the source
factory.addStep(steps.Git(repourl='git://github.com/buildbot/pyflakes.git', mode='incremental'))
# run the tests (note that this will require that 'trial' is installed)
factory.addStep(steps.ShellCommand(command=["trial", "pyflakes"]))

c['builders'] = []
c['builders'].append(
    util.BuilderConfig(name="runtests",
      workernames=["example-worker"],
      factory=factory))

####### BUILDBOT SERVICES

# 'services' is a list of BuildbotService items like reporter targets. The
# status of each build will be pushed to these targets. buildbot/reporters/*.py
# has a variety to choose from, like IRC bots.

c['services'] = []

####### PROJECT IDENTITY

# the 'title' string will appear at the top of this buildbot installation's
# home pages (linked to the 'titleURL').

c['title'] = "Pyflakes"
c['titleURL'] = "https://launchpad.net/pyflakes"

# the 'buildbotURL' string should point to the location where the buildbot's
# internal web server is visible. This typically uses the port number set in
# the 'www' entry below, but with an externally-visible host name which the
# buildbot cannot figure out without some help.

c['buildbotURL'] = "http://localhost:8010/"

# minimalistic config to activate new web UI
c['www'] = dict(port=8010,
                plugins=dict(waterfall_view={}, console_view={}))

####### DB URL

c['db'] = {
    # This specifies what database buildbot uses to store its state.  You can leave
    # this at its default for all but the largest installations.
    'db_url' : "sqlite:///state.sqlite",
}

Answer 1

I had the same problem. It looks like the problem is with WebSocket. From Nginx doco (https://nginx.org/en/docs/http/websocket.html):

To turn a connection between a client and server from HTTP/1.1 into WebSocket, the protocol switch mechanism available in HTTP/1.1 is used.

There is one subtlety however: since the “Upgrade” is a hop-by-hop header, it is not passed from a client to proxied server. With forward proxying, clients may use the CONNECT method to circumvent this issue. This does not work with reverse proxying however, since clients are not aware of any proxy servers, and special processing on a proxy server is required.

Basically you need to properly proxy WebSocket connections. To do that add the following to the Nginx config:

http {
    ...
    server {
        ...
        location ... {
        proxy_pass ...;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Answer 2

I had these exact problems, but first I removed the nginx configuration and used the URL with :8010/ instead. Lazy perhaps, but it works. That fixed part of the problem. Then I found an old bug report here: Link to cached version since the tracker is down atm with the title #2731: [nine] Force build in new UI is not working in chrome

So I simply tried this in Firefox instead. Which worked. This bug was supposedly fixed a year go, but still. After getting it to work in Firefox, it now also works in Chrome.

Anyway. Those two things fixed all of my issues.

Answer 3

The force button does not appear in waterfall view. It only appear in the builder page. Go to Builders page /#builders, the select your builder, and you will see the force button in the top right corner.