openSUSE / obs-service-set_version

An OBS source service: Update spec file version
GNU General Public License v2.0
5 stars 38 forks source link

set_version service incorrectly replaces version with '0.geom.out' , when using tar_scm with two sources on build.opensuse.org #85

Open rhabacker opened 1 year ago

rhabacker commented 1 year ago

Daily updated snapshots packages are built for the vsg project https://github.com/vsg-dev. Due to a change in the project (see https://github.com/vsg-dev/VulkanSceneGraph/issues/784), it is necessary to use two git sources in one package, which fails on build.opensuse.org with an error message

error: Bad source: /home/abuild/rpmbuild/SOURCES/VulkanSceneGraph-0.geom.out.tar.gz: No such file or directory

because in the generated spec file the version is replaced by 0.geom.out, while in a local run it works with osc. Here the version is correctly replaced by e.g. 1.0.5+20230413+git.95ae7957.

See https://build.opensuse.org/package/show/home:rhabacker:obs-tests/test-obs-service-set_version for a corresponding test case.

I also tried obs_scm, which fails with another error.

rhabacker commented 1 year ago

I also tried this with an instance on https://obs-reviewlab.opensuse.org and got the same result.

rhabacker commented 1 year ago

I was wondering where this version 0.geom.out could come from and found it in the repo of the second service:

glslang/Test/baseResults/450.geom.out
glslang/Test/baseResults/420.geom.out
glslang/Test/baseResults/spv.450.geom.out
glslang/Test/baseResults/spv.330.geom.out
glslang/Test/baseResults/max_vertices_0.geom.out
glslang/Test/baseResults/link.vk.multiBlocksValid.1.0.geom.out
glslang/Test/baseResults/spv.150.geom.out
glslang/Test/baseResults/410.geom.out
glslang/Test/baseResults/contradict_0.geom.out
glslang/Test/baseResults/320.geom.out
glslang/Test/baseResults/spv.420.geom.out
glslang/Test/baseResults/150.geom.out
glslang/Test/baseResults/310.geom.out
glslang/Test/baseResults/400.geom.out

So it could be that the version information is extracted from this repo somehow by mistake.

The service file looks as:

<services>
  <service name="tar_scm">
    <param name="scm">git</param>
    <param name="url">https://github.com/vsg-dev/VulkanSceneGraph.git</param>
    <param name="filename">VulkanSceneGraph</param>
    <param name="versionformat">@PARENT_TAG@+%cd+git.%h</param>
    <param name="versionrewrite-pattern">v(.*)</param>
    <param name="versionrewrite-replacement">\1</param>
    <param name="package-meta">no</param>
  </service>
  <service name="tar_scm">
    <param name="scm">git</param>
    <param name="url">https://github.com/vsg-dev/glslang.git</param>
    <param name="revision">VSG-1.0.x</param>
    <param name="filename">glslang</param>
    <param name="versionformat">VSG+1.0.x</param>
    <param name="package-meta">no</param>
  </service>
  <service name="recompress">
    <param name="file">*.tar</param>
    <param name="compression">gz</param>
  </service>
  <service name="set_version"/>
</services>
rhabacker commented 1 year ago

Remove

    <param name="versionformat">VSG+1.0.x</param>

from the second service, the version is generated as <timestamp>.<git-commit-id>, which makes me suspect that the specific versionformat parameter VSG+1.0.x triggers some hidden behavior that causes the originally reported version 0.geom.out to be generated.

rhabacker commented 1 year ago

After the service was executed, the following tarballs grafik were created.

By changing

  <service name="set_version"/>

to

  <service name="set_version">
    <param name="basename">VulkanSceneGraph</param>
  </service>

the set_version service could be made to take the version from the desired tar file.

$ grep Version: _service:set_version:libvsg.spec
Version: 1.0.5+20230413+git.95ae7957

But it is still a mystery how the set_version service gets the wrong version. It doesn't seem to get it from the filename of the other tarball, as it would then have to be VSG+1.0.x.