Hi Pierre,
On 9/8/2016 2:34 PM, Pierre Tardy wrote:
Le jeu. 8 sept. 2016 à 18:25, Neil Gilmore <[email protected]
<mailto:[email protected]>> a écrit :
Hi Pierre,
Thanks for the quick reply.
no problem, it is important for me to track all issues quickly as we
are coming very near the release.
I went over this again, and no steps was not the real problem. The
real problem was that we are creating a worker name that doesn't
exist. The other builders use the correct name, but this one
doesn't. I don't recall seeing any exceptions or logging related
to this, but I suppose I wouldn't, as the master doesn't know when
it starts up who might connect to it.
What do you mean by worker name that does not exist?
Normally you cannot start the master if it has builder connected to
non-existant worker.
https://github.com/buildbot/buildbot/blob/master/master/buildbot/config.py#L825
I probably said that badly, or at least not clearly.
There's no technical problem with master.cfg, and this is not an error
in buildbot.
What we have is a situation where there's no worker process that thinks
it has a name that matches one in master.cfg.
We have a host that runs a worker. That worker has a workername in its
buildbot.tac.
We have a master whose master.cfg has a matching entry in c['workers']
that matches that name. We even have a builder that specifies that name,
and it schedules and builds.
But someone created a c['workers'] entry with a different name, even
though they didn't intend for it to be a different name (the process is
indirect in our master.cfg). The different name is used by a builder.
Nothing happens because the master is really waiting for a worker by
that name to connect, which will never happen. I imagine that if I DID
start up a worker process with this different name, the master would
start having it do the build.
Neil Gilmore
grammatech.com
_______________________________________________
users mailing list
[email protected]
https://lists.buildbot.net/mailman/listinfo/users
