Mailinglist Archive: opensuse-buildservice (144 mails)

< Previous Next >
Re: [opensuse-buildservice] Best option to integrate StartlingX CI with OBS
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Fri, 13 Sep 2019 08:00:13 +0200
  • Message-id: <2896016.T7eh0vEdDk@linux-ywca>
On Donnerstag, 12. September 2019, 16:51:34 CEST Dominig ar Foll (Intel Open
Source) wrote:
Hello,

I have spent a few hours at looking at various options on how best
integrate StartlingX CI with OBS for our multiOS subproject.
For info, StarlingX is a pilot project of OpenStack.
https://www.starlingx.io/

I notice when looking at information on OBS and CI integration published
by projects like OpenStack or obs-server that that prefer process seems
to be, first build in a branch, followed by a second build in staging.

It leads me to a few questions:

1) Why 2 builds
------------------------
What s the value of building of a package in Staging if that was already
validated in a Branch ?
Is there something that I missed that is possible in Staging but not in
a branch ?

You could build in project A and use the release mechanism to move sources
and binaries to project B. Would that solve your issue?

2) Managing builds
------------------------------
I do not have the knowledge of a build ID concept on OBS and that make a
few things more difficult. I would be interested to understand the best
way to work around.
After creating my branch and changing the required files, my build can
be tracked by osc.
osc results -w --xml home:dominig:branches:.......
The -w option might not be a good idea as I can see that SSL Error:
(104, 'Connection reset by peer') are quite frequent.
Is there a better asynchronous way to track the package build
success/failure?

hm, osc should maybe handle such an errror better, no idea where it comes
from atm ...

If multiple changes are triggered in parallel on the same package, I
would have a mess with my branches (naming conflict). What would be the
best method to avoid serialisation on the test builds in that case ?

you speak about to build each commit independend in own projects?

You could hand over a project name which includes the pull request number?

3) Cancelling build
------------------------------
It is not uncommon in a CI, that a new patch set is added before that
the build result is known. What would be the best way to manage such
situation ?
Would an "osc restartbuild" on the same branch after source update the
right solution ?

Hm, you could set it up in way that OBS gets notifications on source changes
and is doing so automatically...

Any other hints for CI integration would be welcome.

some old blog about that:

https://openbuildservice.org/2013/11/22/source-update-via_token/

https://openbuildservice.org/help/manuals/obs-reference-guide/
cha.obs.authorization.token.html#id-1.7.18.4

https://openbuildservice.org/help/manuals/obs-user-guide/
cha.obs.source_service.html
--

Adrian Schroeter <adrian@xxxxxxx>
Build Infrastructure Project Manager

SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
(HRB 247165, AG München), Geschäftsführer: Felix Imendörffer




--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >