Since we're dependent on postgres and django, and since the combs are docker-dependent, what do we think about setting up docker-compose.yml for local development?

If we (and I think here we might mean just @freakboy3742 😛 ) thinks this is an ok idea, I'll get this spun up.

The link to Read The Docs in the README points to documentation for https://github.com/haikuginger/beekeeper, not the BeeWare BeeKeeper project.

(I was wondering how Roy Fielding's REST API and HATEOAS principles applied to CI...)

Right now every time @brutusthebee does anything I want to give feedback on, I'm never sure if it's an issue for pybee/beekeeper of pybee/beefore. (Even as I'm writing this, I'm not sure if it's more suited for beefore)

A link in @brutusthebee's bio or even in his comments will help clarify this confusion and streamline the feedback process

flake8 testing of https://github.com/pybee/beekeeper on Python 3.7.1

$ flake8 . --count --select=E9,F63,F72,F82 --show-source --statistics

./projects/models.py:69:16: F821 undefined name 'Commit'
        except Commit.DoesNotExist:
               ^
./aws/models.py:244:83: F821 undefined name 'profile_name'
            raise RuntimeError("Unable to find a '%s' profile - is it defined?" % profile_name)
                                                                                  ^
2     F821 undefined name 'profile_name'
2

E901,E999,F821,F822,F823 are the "showstopper" flake8 issues that can halt the runtime with a SyntaxError, NameError, etc. These 5 are different from most other flake8 issues which are merely "style violations" -- useful for readability but they do not effect runtime safety.

• F821: undefined name name
• F822: undefined name name in __all__
• F823: local variable name referenced before assignment
• E901: SyntaxError or IndentationError
• E999: SyntaxError -- failed to compile a file into an Abstract Syntax Tree

BeeKeeper currently uses AWS Elastic Container Service (ECS) to deploy build jobs. However, this is an AWS-specific API.

Amazon just announced EKS - Elastic Kubernetes Service - which would still be an Amazon service, but would allow us to use Kubernetes APIs, rather than proprietary AWS ones.

This should ultimately allow end users to run their own build clusters on their own machines, or deploy to infrastructure other than AWS.

We need someone to investigate the feasibility of this, and if it's plausible, implement a port to EKS (ideally abstracting away any AWS-specific API calls)

Currently, the pull request handler figures out which commit to test by retrieving payload['pull_request']['head']['sha']. However, this is the latest commit on the head branch (as opposed to the base branch, which is the one changed once the PR is merged).

The behavior on Travis CI is different, per their Building Pull Requests doc:

Rather than test the commits that have been pushed to the branch the pull request is from, we test the merge between the origin and the upstream branch. To only build on push events, you can disable Build on Pull Requests from your repository settings.

I believe the other online CI systems are similar, but I'm just using Travis CI as the example as that's what I'm familiar with from working on VOC.

GitHub provides this commit sha in the ['pull_request']['merge_commit_sha'] field, and as explained a note box in their Pull Requests api docs:

Each time the pull request receives new commits, GitHub creates a merge commit to test whether the pull request can be automatically merged into the base branch. (This test commit is not added to the base branch or the head branch.)

The value of the merge_commit_sha attribute changes depending on the state of the pull request. Before a pull request is merged, the merge_commit_sha attribute holds the SHA of the test merge commit. After a pull request is merged, the attribute changes depending on how the pull request was merged: [...]

I think that we should test this merge-commit-of-head-into-base-branch instead of the latest commit on the head branch, because there are circumstances where the head branch may pass CI (due to it being mergeable without file conflicts), but the way git happily does the merge leaves the base branch (master) in a failing state. I vaguely remember that Travis has caught this case in at least one VOC PR before?

For discussion perhaps? I am not too sure if there is further impact on the Beekeeper/Beefore/etc as a result of making this change.

The code reviews in This pull request all point to the wrong lines.