Aidan Kahrs

Here are a few option: Self hosted [COPR](https://pagure.io/copr/copr/blob/master/f/copr-setup.txt) Bash scripts and git hooks [mock-scm](https://github.com/rpm-software-management/mock/wiki/Plugin-Scm) config options to make a tarball

True. It is likely though that the build system will be on our infra unless we can find a good hosted way to do RPM builds. Also needs to be...

@jflory7 Licensing might be an issue. Also COPR may want to have one repo per package.

@ct-martin Travis is a no go. This is gonna be interesting with COPR. Biggest concern is licensing. I would go with automating our self hosted stuff (maybe ala [this](https://blog.mornati.net/build-rpms-for-a-git-github-project-with-jenkins/) substituting...

for help with using tito as describe above in hosted COPR and getting COPR to work with our subdir based approach talk to `clime` in `#fedora-buildsys` on `freenode`

ideas: - Lightweight build system section here https://www.hogarthuk.com/?q=node/11 - https://wiki.jenkins-ci.org/display/JENKINS/RPM+Sign+Plugin - https://github.com/jhrcz/jenkins-rpm-builder - https://schneide.wordpress.com/2013/03/18/1-click-deployment-of-rpms-with-jenkins/ @ct-martin

ok. so we should probably use tito in some way to get around the subdir part. we can run tito with jenkins to trigger. signing can likely use the jenkins...

Test with standard web server directory since that should have proper selinux context

New idea for RPMs, GitLab runner on buildbox that talks to the GitLab.com instance of the project and does per branch rebuilds. we can use the `only` option to restrict...

So I am talking with @ritjoe a little and he was favoring the idea of one package per repo. We would still need to workout a way to hook our...