bs_service allows concurrent runs for the same package when committing individual _service file revision

[gollub]

Our CI generates a _service files and commits that on every push to our Git servers.
The _service files hold as revision the Git commit hash for the tar_scm or git-buildpackage source-services. (Each push is a new _service file revision).

If someones does a second push, while the first source-service run is still running, a second source-service job get spawend for a new Git/package revision for the same OBS project/package.

(IIRC I have seen even cases where the source-service max number of jobs got reached (5 concurrent runs) for the same package - for larger repos and where the CI did by accident several pushes for the same project/package)

Seen on OBS 2.6.

[adrianschroeter]

We plan the new git mirroring support for 2.7. I hope these kind of problems well be away then.

[gollub]

Does that git mirroring support still allow to run custom source-services?

E.g. for Debian packaging we need to run "git-buildpackage -S" to generate a Debian build-description (.dsc file) out of a Debian Git tree.

[adrianschroeter]

The packaging will happen during build time using source service in buildtime mode. So, you can do even more there, since you can influence the used service packages.

The only downside is when your scripts are needed to allow the source server to parse the build dependencies.

[gollub]

Ok, I see. This is unfortunately the case for git-buildpackage -S.

Our OBS package usually consists just of a _service file. No further files.
The source-service generates the .dsc build-description - which holds the build-depends.

Example _service file:

<services>
<service name="git_buildpackage">
  <param name="url">ssh://git-server-url/easy-rsa.git</param>
  <param name="revision">$commit_hash</param>
  <param name="dch-release-update">enable</param>
</service>
</services>

Which results in those generated files:

_service:git_buildpackage:easy-rsa_2.2.2-1.debian.tar.xz
_service:git_buildpackage:easy-rsa_2.2.2-1.dsc
_service:git_buildpackage:easy-rsa_2.2.2.orig.tar.gz

[adrianschroeter]

right, we should be able to lookup also build descriptions files directly from git repo. Just when you need to run code to create/modify them in addition you will have a problem.

[gollub]

Yes. This is unfortunately a current trend in Debian. For example:
http://anonscm.debian.org/cgit/collab-maint/openvpn.git/?h=debian/2.3.4-3

At the moment obs-build and the build-recipe-dsc is parsing this file:
http://debian.mirror.lrz.de/debian/pool/main/o/openvpn/openvpn_2.3.4-5.dsc

Which is the result if you build a Debian source package (dpkg-buildpackage -S .. or git-buildpackage -S).

But I guess the majority of information required for the scheduler could be obtained from the debian/control file itself:

http://anonscm.debian.org/cgit/collab-maint/openvpn.git/tree/debian/control?h=debian/2.3.4-3

[mlschroe]

Sure, parsing the control file is probably the right thing to do, as the dsc file is actually a build output and not input file. The control file is normally (at least in former times) buried inside some diff file, and it also lacks the version information which needs to be extracted from the changelog. So I went with the dsc file instead (i.e. pushed the burden of the information extraction to the used ;) )