Per discussion on moby/moby#28143 (comment), we should have a way to detect if labels on an issue were manually corrected. This may be a difficult one, but initial thoughts;

• add a label "manual-override" (e.g.) that tells poule to not apply labels
• detect if the issue/PR has a "person X removed label xyz" action, and if so, don't re-apply that label (may be expensive)
• detect if labels of a specific kind are already present (e.g., if a "area/xyz" label is already present, don't add a different area, likewise for "kind/xyz")
• other suggestions?

/cc @icecrime @ehazlett

The validate command should be able to validate both:

• Global configuration files.
• Repository specific configuration files.

We can use then this in CI jobs.

Description

The tool should have a long-running mode where it subscribes to a set of repositories, as defined by a configuration, and applies operations on the fly as GitHub webhooks are triggered.

What should be done?

The configuration should allow to define:

• Sets of operations.
• Mappings between GitHub events (e.g., pull request event with "created" action) to operations.
• Mappings between GitHub repositories and event sets.

Typically, we use NSQ rather than directly subscribing to GitHub events. This is pretty much a Docker idiosyncrasy, and it would be better if the tool cool support both.

and its yucky

As per the documentation, CircleCI 1.0 will be sunset August 31, 2018.

CircleCI 2.0 offers many improvements but is not backwards compatible. The YML file will need some minor refactoring.

Finish the prune operation, which should be capable of:

• Pinging the original author for items which have shown no activity for a specified amount of time.
• Warning the original author that the item will be closed unless it shows activity under a specified amount of time.
• Close the item after the warning has been issued.

From leeroy: we should whitelist the release branch from the DCO-check.

Questions:

• Should we harcode this behavior in the operation?
• Should we provide a configurable whitelist of branches? (but then, dco-check will need to be configured differently for different repos)

The rebuild operation currently supports a single trigger label. If you want to configure multiple label to configuration associations, you need to repeat yourself in the configuration:

- repositories:     [ "docker/docker" ]
  triggers:
      pull_request: [ labeled ]
  operations:
      - type:       rebuild
        settings: {
            configurations: [ arm ],
            label:          "rebuild/arm",
        }
      - type:       rebuild
        settings: {
            configurations: [ experimental ],
            label:          "rebuild/experimental",
        }

Question: is that a good approach, or should rebuild made aware of a label to configuration mapping?

The dependency on NSQ makes the project harder to deploy: add an option to serve-mode that listens on HTTP and can directly accept GitHub webhooks.

Description

The tool's output so far is strictly using the standard log package, with a few extra fmt.Printf in the entrypoint commands.

What should be done?

Evaluate whether it would be better to:

• Move away from logging.
• Switch to a richer logging library (such as Sirupsen/logrus.
• Leave it as it.

Take advantage of moby/moby#31257 in the Dockerfile to produce a minimal image.

We had a feature that automatically added a "status/claimed" label if a user commented #dibs. Looks like that is not (yet) supported by poule, e.g. moby/moby#28766 (comment)

/cc @icecrime @ehazlett

Description

Golang is adding support for plugins: we should leverage that! This would allow projects to add non-generic operations for their particular use case (which probably version-label and others in the current tree probably should be).

What should be done?

The tool should look for plugins in a subdirectory, and dynamically load any operations it can find. The plugins would likely provide the OperationDescriptor interface.

Hi @icecrime I was chatting to Justin Cormack today and I'd like to raise a PR to categorise Raspberry Pi issues as platform/arm. Are you OK with this?

Can you direct me to the live config?

Potential bonus points for picking up someone running helloworld:latest and getting an error due to wrong architecture.

moby/moby#29617

Description

The dco-check strategy is the most critical before deploying the tool for docker/docker: it needs test coverage before we do so.

What should be done?

Following other example of tests which use a mocked GitHub API, test the different scenarios of signed/unsigned commits, and actions when the state of the pull request changes.

A PR was "stuck" (moby/moby#30303) in that no build was triggered and when adding the rebuild/arm label the following error was thrown:

time="2017-02-13T21:41:25-05:00" level=info msg="running operation" number=30303 operation=rebuild repository="docker/docker" 
time="2017-02-13T21:41:25-05:00" level=debug msg="rejecting pull request without label \"rebuild/*\"" 
time="2017-02-13T21:41:25-05:00" level=debug msg="received GitHub event" action=unlabeled event="pull_request" number=30303 repository="docker/docker"

I could add the rebuild/* label and Gordon would remove it but nothing would happen. I even tried to add both rebuild/* and rebuild/arm but Gordon just removed the rebuild/* label and threw the error above leaving the rebuild/arm label on the issue.

My vote would be to remove the wildcard label and force people to be explicit about what they want rebuilt.

Implement an operation capable of recognizing that a pull request is the first ever submitted to the project by a contributor, have a nice welcome comment to point to our communication channels, and label accordingly. Maintainers should take that information into account during review.

Instead of having a single configuration file for all repositories, poule could get the YAML configuration from the repositories themselves (e.g., a poule.yml at the root).

Hi

Just wondering if there any other specific config that needs to be done to send the webhook to this when running in server mode. I've set it up as per the documentation, but I'm getting 404's when I curl localhost as well as from github.