.. | ||
.gitignore | ||
.python-version | ||
bot.py | ||
build_commands.py | ||
README.md | ||
requirements.txt | ||
run.py | ||
server.py | ||
yw.jpg |
slack buildbot
General Function
-
There are two global locks,
repo
andrelease
. Therelease
bot command uses the release lock, all other commands use therepo
lock. This means that you can run any non-release command and a release command simultaneously. You cannot currently run multiple build commands simultaneously.- The per-user build environments described below should provide a good starting point for breaking the
repo
lock into multiple more granular locks. The primary issue with this as of Oct 2018 is the reliance on the windows VM to build windows plugins. This resource would seem to require some additional work to make build commands run in parallel.
- The per-user build environments described below should provide a good starting point for breaking the
-
When a user sends commands to the bot via slack, the bot will use (and create if necessary) a new isolated repository on the box running the slack bot.
- It sets up a
~/build_repos/<USERNAME>/
directory as the GOPATH, and attempts to initialize a new go environment rooted in this directory.
- It sets up a
-
Start the bot with
SAFE_MODE=true
set in the environment to make most (all?) destructive operations into noops. This means there should be no PRs created for bindata, no pushes for modified repos, etc.- Note: This was a hastily built feature for development purposes, so don't assume it's going to make all operations 100% safe. It's likely still possible to break things with some edge case or another, so think through the commands you're going to run even with
SAFE_MODE
enabled. That said, I'm leaving the functionality in the repo for future devs to simplify their process some.
- Note: This was a hastily built feature for development purposes, so don't assume it's going to make all operations 100% safe. It's likely still possible to break things with some edge case or another, so think through the commands you're going to run even with
Oddities and Gotchas
-
FIRST USER COMMAND ISSUE There is a known issue where the macos plugin build may hang indefinitely without an error message while trying to call
xcodebuild
. The fix for this is to manually open the.xcodeproj
file once in xcode by double clicking it in the finder. The path should be something like~/build_repos/<USERNAME>/src/github.com/kiteco/kiteco/osx/Kite.xcodeproj
.- I wrote a short script that automatically attempts this step, though I'm not sure that it fixes the problem, despite being the same steps that are performed manually. -nick johnson
-
Building submodules If you're developing a new plugin submodule for the first time, you will have to manually go into solness, into your folder in
~/build_repos
, and do agit submodule update --init