Ok, our Web-UI and API should have two config options:

• Subdirectory -- where all the sources are located, and the work is
  done (spec file is found, etc.)

• Webhook trigger patterns -- a list of regular expressions; when any
  file from changes in the webhook trigger match any of the pattern
  specified, build is submitted.

We use the current subdirectory for both purposes, and it is not always
flexible enough. I'm dropping @dturecek from the assignee field as nobody
is working on this for some time.

Duplicate #771

Another thing that doesn't scale is that we have only one build-method per
package; and with that is bound that we can have at most one way to
trigger a build by the webhook per package.

Consider situation that one package builds from two source tarballs, both
coming from a different upstream (it typical situation for packages that
bundle other software).

We'll want to trigger build for such package both for commits inside the
main project URL, but also for the secondary (bundle) git repository.
Depending on which git url triggered this, we may want to pick a
different method for building the sources.

It would be much more scalable if we entirely separated the "build
triggers" configuration (currently webhooks) from the package, in relation
1:N. And if we could 1:N map build methods to one package.

The relations could look like:

[Package]  1 ----> N  [BuildTrigger]  1 -----> 1  [BuildSpecs]
[Package]  1 ----> N  [BuildSpecs]

BuildTrigger == {
  "clone_url": ...,
  "subdir_patterns": ...,
}

BuildSpecs = roughly the equivalent and alternative to source_type + source_json

This issue has been migrated to GitHub: https://github.com/fedora-copr/copr/issues/335