On Thu, Apr 20, 2017 at 10:23:53AM +0200, Stef Walter wrote:
On 19.04.2017 14:40, Pierre-Yves Chibon wrote:
> On Wed, Apr 19, 2017 at 02:24:01PM +0200, Frederic Lepied wrote:
>> On Wed, Apr 19, 2017 at 2:14 PM, Pierre-Yves Chibon
<pingou(a)pingoured.fr>
>> wrote:
>>
>> Hi all,
>>
>> I have created a small project on pagure to host sources and files
>> around the CI
>> effort:
https://pagure.io/fedora-ci-overview/ feel free to go over it if
>> you
>> wish.
>>
>> Ari and I created a few of diagrams:
>> -
>>
https://pagure.io/fedora-ci-overview/raw/master/f/CI-pipeline_20170414-3.png
>> Â represents the CI pipeline "pre-merge" (ie: before and up to a
change
>> land on
>> Â the main repos of dist-git)
>> -
>>
https://pagure.io/fedora-ci-overview/raw/master/f/centos-ci-pipeline-deta...
>> Â this is an overview of the different tests performed
"post-merge"
>> -
>>
https://pagure.io/fedora-ci-overview/raw/master/f/Fedora_CI_pipeline_2017...
>> Â this is from this morning and still needs to be discussed/validated,
>> but
>> Â represents my current understanding of the CI pipeline pre and post
>> merge for
>> Â Fedora Atomic Host images.
>>
>> Comments and questions are of course welcome :)
>>
>> Â
>> How does it work when the packager himself wants to do a change? Will we
>> require the same process: PR, review and merge on himself?
>
> There are two options:
> - either the project on pagure requires a PR workflow and then the packager can:
> - Open a PR
> - Mark it to be merged directly
> - Let the system merge the PR when and if all the tests pass
> - or the project does not enforce the PR workflow and everything pre-merge is
> ignored, the packager can push to dist-git as they do now and nothing changes
> for them
>
> In a CI world, I think we would prefer the first case :)
Is Bodhi the only point of gating here?
Post-merge, currently, yes
I don't see gating (on failure) mentioned explicitly in the
workflow.
Hence the question:
"Will a broken change 'pushed to main repo in dist-git' (one that
does not pass CI) affect other packagers or the composed artifact
in general?"
Not until it passes bodhi.
That's one reason why taskotron gets kick off by bodhi update, before bodhi
everything can be just the packager testing things. Commits to dist-git or build
in koji does not mean the artifact will go to the repo and does not influence
other packages.
Bodhi will allow to do buildroot override, thus allowing to include a
non-released build into the buildroot of another package (likely depending on
the first one), that is the earliest time a build can influence another one.
After that, the build will influence others when it is pushed to
updates-testing.
Hope this helps,
Pierre