[Rdo-list] [Softwarefactory-dev] Gitnetics integration, or how can we automate upstream changes polling

[Fabien Boucher]

Hi,

Le 05/02/2016 15:06, Gabriele Cerami a écrit :

> If the patches are never merged how do you know they don't create
> conflicts, what is the merge base of the patches ? patches are never
> rebased on each other but only to a common base ?

In the RPM Factory context let's say we have a project "A" packaged for Liberty.
"A" is packaged at version 1.0 and 2 patches are needed. Then we have liberty-patches
branch reset on tag 1.0 and :
- patch 1 (gerrit review) has liberty-patches HEAD as parent
- patch 2 (gerrit review) has patch 1 as parent.
So the base is liberty-patches HEAD (or the tag 1.0). If you
"git review -d <gerrit_id of patch 2>" -> you fetch tag 1.0 + p1 + p2
already applied. 

> Since SF is package-centered, I know this is less relevant, because all
> the patches end in the package at some point, and you test that.
>> About the master version of RDO, AFAIK yes Delorean does not use any
>> patches when
>> trying to use rpm-master distgit to test the packaging against each
>> upstream changes
>> so there is not need to run unit test in that case IMO.
> 
> Unit tests, no. Acceptance tests, yes. Upstream CI will never be enough
> because all the projects always download bleeding edge versions for
> dependencies that may not be present, or have different version in the
> distro packages.

Yes sure if a project or a puppet module embed a functional test suite
(like Beaker for a puppet module) then we should definitely run them each time
a change is proposed again a distgit.
For instance when a maintainer, of one of the future splited OPM, proposes on new change
(Gerrit review) on the distgit then the RPM of the puppet module is built and
is installed on a fresh test node (dependencies, configured in the RPM, are installed)
and then the acceptance tests (Beaker) will run. I think we can easily
give an adequate feedback to the packager especially dependencies issues.
After all this is one of the job of a package maintainer -> dealing with
package dependencies :)
In the context of RPM Factory, note this behavior can only work for stable
branches rdo-liberty, "rdo-mitaka', not with rpm-master.

>> 2. until then, we can just use our own mirrors instead of upstream
>> 3. depending how much time, it'll take, it would be worth considering
>> having vanilla puppet modules packages available for testing
>> Moreover associated w/ delorean, it will help us to catch glitches as
>> soon as puppet modules gets broken.
> 
> One of the big things I'm trying to undestand here, is how much test do
> we want, on OPM and in general.
> OPM-CI is currently trying to run tests after each upstream change is
> merged, but before the same change is merged downstream. After this, a
> package may be created and tested with the rest of the puppet modules,
> but testing before merge catches errors very early in the chain, and we
> immediately know which package caused the havoc, because we are testing
> only one, not the entire set of modules at once.

Should splited OPM be managed the way as the other RDO packages ?
I mean Delorean uses the rpm-master to test packaging of each OPM packages
and the CI tags the repo as "current-passed-ci" when validation jobs pass.

> 
> Fabien, can we begin to transfer gitnetics jobs to SF ? I'd like to
> know what happens when the two meet.
> 

Yes sure we can discuss how to test both together. Let's ping me on
IRC.

Cheers,
Fabien

> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at redhat.com
>