2

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",
}
meh
  • 2,591
  • 4
  • 20
  • 33
  • Can you upload your config? primarily the bit which sets up the schedulers. Also your nginx config - have you copied the example config provided in the buildbot tutorials? – Jonny Paton Jul 13 '17 at 13:14
  • Yes it is the default config you get when you do `mv master.cfg.sample master.cfg`. I've added it as an edit. – meh Jul 14 '17 at 14:49
  • I spoke briefly with tardyp, who answered the question below, and he says it may be due to the fact I'm not forwarding websockets properly. I'm using Nginx and the websocket forwarding directive did not work on simple http. I've yet to try it with https. That will be my next attempt. – meh Jul 14 '17 at 14:53
  • Yes I had the same issue with nginx, had to modify the nginx config in the tutorial to get it to work, what's your nginx config like? – Jonny Paton Jul 14 '17 at 15:28
  • I have exactly the same issues, although slightly different configuration. I run them in rkt containers. I also use nginx though. Anyone care to share a nginx configuration that works? – Darakir Aug 08 '17 at 12:22
  • What I did was simply remove the nginx config and use the URL with :8010. That did solve the intermittent disappearing links under the Builds menu. Not the missing link in the Waterfall view though, but the force build button showed up, so kind of?. – Darakir Aug 08 '17 at 12:40

3 Answers3

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;
    }
}
Ilia Frenkel
  • 1,969
  • 13
  • 19
0

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.

tardyp
  • 1,142
  • 11
  • 9
  • Thanks tardyp, it is not there either. I'll clarify in the question. You have other suggestions? – meh Jul 10 '17 at 13:47
  • @tardyp, So is the documentation for the http://docs.buildbot.net/current/tutorial/tour.html#your-first-build incorrect? Should it specify `localhost:8010/#/builders` ? – chrish Aug 18 '17 at 14:42
0

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.

Darakir
  • 166
  • 2
  • 9