KAuth buildability: new CI architecture

[Ben Cooksley]

On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter <sitter at kde.org> wrote:
> Not particularly related to the issue at hand (which is probably
> polkitqt having meh cmake files), but relocating stuff in general is
> suuuuper unreliable and I would absolutely advise against it as it can
> easily screw up test results and builds alike, often in unobvious ways
> (all it takes is a bit of libexec use). Instead, as a general
> principle, I would suggest that you get stuff mounted in suitably
> stable/consistent/generic paths inside the build containers.
> Ultimately what things look like natively on the host file system
> shouldn't factor into what they look like in the build environment.

While I have thought of using a consistent path, this would simply
workaround the fact that our binaries are frail and have hardcoded
paths baked into them.

The CI has always run an unusual configuration as part of it's job is
to find brittle parts of our codebase and make the breakage visible.

Outside of traditionally provided FOSS packaging, relocatable binaries
are something we'll need - for Windows packages for instance as users
there expect to be able to specify the installation directory (on that
note - log for kcoreaddons on Windows is attached with several test
failures, and it looks like the logic around ASAN on Windows needs
adjustment too).

We'll see how things go.

>
> For example, in neon we simply mount everything into /workspace of our
> containers.
>
> You could have
>
> /workspace
> |_ src/      [on host: /home/jenkins/workspace/polkit-qt-1 kf5-qt5 XenialQt5.7/
> |_ install/  [on host: /home/jenkins/workspace/polkit-qt-1 kf5-qt5
> XenialQt5.7/install-prefix/]

The workspaces are, on the Linux systems at least, thrown away at the
completion of a job. The only thing that survives is a tarball archive
of the files installed by the job.

>
> Notably advantage is that relocation issue get entirely eliminated as
> the install prefix is always the same, and as an added bonus paths
> become much shorter and easier to read in the build logs.
>
> It also detaches the build tooling from the host tooling. e.g. the
> build code at this point no longer needs to care about which path
> Jenkins was installed to, or where it was configured to put
> workspaces, or what the jenkins job name is, or if jenkins is even
> still used.
>
> Food for thought :)
>
> HS

Cheers,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcoreaddons-windows-build.log
Type: application/octet-stream
Size: 96525 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170416/2b74effa/attachment-0001.obj>