A QA project can get configured to also rebuild the sources again based
on the binaries of other packages of the QA project.
This is esp. useful for bootstrap projects. We would keep the main
project in this case to ensure that the package itself is building
on current code base. But we would also test if it breaks other packages
or fail during bootstrap cycle.
Using the BuildDisableRepos configuration, it is now possible to
define which repositories to build-disable in the QA project meta.
This is for example useful for the SLES development workflow, where
the product repository should only be enabled after the packagelist
definitions have been built - so it is not desirable to have them
built as soon as the QA project is created.
Example:
{
"ObsProject": "SUSE:SLFO:Main",
"StagingProject": "SUSE:SLFO:Main:PullRequest",
"QA": [
{
"Name": "SLES",
"Origin": "SUSE:SLFO:Products:SLES:16.1",
"BuildDisableRepos": ["product"]
}
]
}
Signed-off-by: Eugenio Paolantonio <eugenio.paolantonio@suse.com>
That way a source merge of any product is not triggering rebuilds in
pull request QA sub projects. We may need a config option here to
enable/disable this.
They need to keep access as they might need to be able to modify the
stage project. They could grant access anyway, by adding themselfs
as they own the upper project. No reason to force them the
extra trip or to hide build results first to them
The build result request of the base project is failing in this
situation, since the requested package does not exist.
Therefore we need to have seperate lists for proper handling.
Add cleanup logic for finished requests
Merged PRs are immediatelly removed along with any QA subprojects
Unmerged closed PRs are removed after a day, default 48 hours
since closing.
Repositories which build against another repo in the same project need
to do so also in the forked project. This is eg for consuming rpms
from one repo in an image build from same project.
