On Mittwoch, 29. Juni 2016 13:34:33 CEST Harald Sitter wrote: > On Wed, Jun 29, 2016 at 1:11 PM, Ben Cooksley <[email protected]> wrote: > > On Wed, Jun 29, 2016 at 10:49 PM, Daniel Vrátil <[email protected]> wrote: > >> On Wednesday, June 29, 2016 12:24:10 PM CEST laurent Montel wrote: > >>> Le mercredi 29 juin 2016, 21:02:24 CEST Ben Cooksley a écrit : > >>> > Hi all, > >>> > > >>> > It would appear that PIM has bumped it's Grantlee dependency without > >>> > any announcement. > >>> > > >>> > Failing that, commits are missing from one or more of the PIM family > >>> > of repositories, the build metadata is out of date, or the CMake > >>> > infrastructure of the PIM repositories is insufficient to work within > >>> > the CI environment. > >>> > > >>> > Please see > >>> > https://build.kde.org/view/FAILED/job/messagelib%20master%20kf5-qt5/32 > >>> > 5/PL > >>> > A > >>> > TFORM=Linux,compiler=gcc/console > >>> > > >>> > Please correct this and provide an explanation for the issue. > >>> > >>> The problem is a grantleetheme problem. It was a bad commit. > >>> It's fixed. > >> > >> Note that GrantleeTheme is our internal library. > >> > >>> > PIM buildability continues to be an ongoing and major issue - > >> > >> Excluding honest mistakes like this one, our only issue is with build > >> order > >> due to API changes across modules. If I break API in one module and push > >> a fix to another module that depends on the new API, it will break if it > >> finishes before the first one. If I wait with pushing the API adjustment > >> in the other module but someone else triggers the build anyway, we have > >> the same problem. We cannot prevent this easily unless the CI can ensure > >> build order....> > > Something we can't do > > Well, not with that attitude we can't ;) > > I'd do the following > - define new commit keyword ABI-BREAK > - Jenkins finds keyword in commits to integrate > - Jenkins blocks implicit downstreams (that is: downstreams as per > metadata dependency tree, not actual jenkins downstreams, although > that's also a possibility I suppose) > -- the actual nature of how this is achieved is what one would need to > look into. a possible option would be to create a temporary job that > is run in parallel but simply sleeps all the time and has the relevant > blockees as downstreams and the breaking job as upstream. when > upstream finishes it kills the temporary job thus unblocking all > downstreams.
This sounds awesome and we'd need that as well in KDevelop land. Bye -- Milian Wolff [email protected] http://milianw.de
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
