I cannot reproduce the problem, even if I install e26b0ae.

But I´m wondering about your settings - you have set the CACHEDIRECTORY, but maybe you might want to disable this. When running in osc, the local osc working copy will include the directory of the clone and also be used for caching. But I also have to admit, that this is no explaination for this problem and why I cannot reproduce it.

Maybe you could disable the CACHEDIRECTORY in your setting and try if the problem still exists.
This settings can be done in

/etc/obs/services/tar_scm
or
~/.obs/tar_scm

I am running into this too and I have some more information. This is reproduceable if CACHEDIRECTORY is set to anything but the empty string in ~/.obs/tar_scm and if the env var OSC_VERSION is set to anything: http://paste.opensuse.org/5156bb0a

When CACHEDIRECTORY is set, a bare clone is made:

When it prepares a working copy from the CACHEDIRECTORY, it uses --no-checkout, which causes the working copy to start empty:

Then it is supposed to check out the given revision which would make it no longer empty, but if OSC_VERSION is set (which happens when invoked by osc) there is this funny behavior with git-stash on an un-checked-out tree, where restoring the stash causes the tree to be empty again even after the hard reset:

The result is that when this is invoked by osc service disabledrun the obscpio file ends up basically empty and the package won't build.

@cmurphy Thanks for your detailed explaination. Now I see the problem, but as already said:

I don't see any use case in using a CACHEDIRECTORY within "osc" as in the osc case the git repo gets already cached in the osc working copy, but I would like to hear your comments.
@adrianschroeter, @aspiers, @frispete ,@cmurphy - Is there any use case for this, that I don`t see?

I only see, that you have to remove the local checkout in the osc working manually before triggering the next service run - thats an real disadvantage for me.

Maybe we should throw an exception (or at least print a warning) if you try to use a CACHEDIRECTORY while calling from 'osc'?

In my case I am pretty sure I didn't set CACHEDIRECTORY myself, something else must have generated ~/.obs/tar_scm but I'm not sure what. An error message warning about it would be an improvement, though maybe frustrating if either tar_scm or osc or some other tool is creating it without the user's knowledge.

Nor osc neither obs-service-tar_scm should have created a file in your home. IMHO it is common sense, that rpms do not create files in users home directories (for good reason).

Thanks @cmurphy for the great analysis!

I reproduced this by accident just now ...

@M0ses commented on 13 Jun 2018, 10:03 BST:

I don't see any use case in using a CACHEDIRECTORY within "osc" as in the osc case the git repo gets already cached in the osc working copy, but I would like to hear your comments.
@adrianschroeter, @aspiers, @frispete ,@cmurphy - Is there any use case for this, that I don`t see?

Sure - the cache is supposed to be global (or at least per-user) not per working copy. This is in case you have multiple osc branches of the same package, because then it means you only need one clone into the global cache, rather than one per package.

I only see, that you have to remove the local checkout in the osc working manually before triggering the next service run - thats an real disadvantage for me.

If that's true (why would it be?) then IMHO it's a bug.

Maybe we should throw an exception (or at least print a warning) if you try to use a CACHEDIRECTORY while calling from 'osc'?

Definitely not - IIRC I originally designed the cache for client-side usage. Server-side efficiency was just a bonus :-)

I did some archaeology and the stash code comes from 4e4b2d66.

Here is the debug I obtained by manually hacking a workaround to #240:

POST https://api.opensuse.org/source/home:aspiers:branches:server:monitoring/lnav?cmd=getprojectservices
Run source service: /usr/lib/obs/service/tar_scm --url git://github.com/aspiers/lnav.git --scm git --exclude .git --versionformat 0.8.3b+git.%ct.%h --revision sp3 --changesgenerate enable --outdir /home/adam/SUSE/OBS/home/aspiers/branches/server/monitoring/lnav/tmpDmDG_t.tar_scm.service
Ignoring config files: test-mode detected
Using fakeheader for file '/etc/obs/services/tar_scm'
Using fakeheader for file '/home/adam/.obs/tar_scm'
SECTION: tar_scm
REPOCACHE: /home/adam/.obs/cache/tar_scm
CACHEDIR: '/home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f66348747c'
SCM: 'git'
Stripping 'git' extension from '/aspiers/lnav.git'
 - New  url_path: '/aspiers/lnav'
[_calc_dir_to_clone_to] CLONE_DIR: /home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f66348747c/lnav
REPOCACHEDIR = '/home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f66348747c'
[fetch_upstream] Initial checkout/clone to directory: '/home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f66348747c/lnav'
COMMAND: ['git', 'clone', '--mirror', 'git://github.com/aspiers/lnav.git', u'/home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f66348747c/lnav']
RESULT(0): "Cloning into bare repository '/home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f66348747c/lnav'...\n"
COMMAND: ['git', 'rev-parse', '--verify', '--quiet', 'sp3']
RESULT(0): '3d19d0865693847c1e1b3b8133faecae155946a9\n'
COMMAND: ['git', 'clone', '--no-checkout', '--reference', u'/home/adam/.obs/cache/tar_scm/66c4d41370d7046aa194a4c9616f4a599cf50023b54d88182a4d50f6
6348747c/lnav', 'git://github.com/aspiers/lnav.git', '/home/adam/SUSE/OBS/home/aspiers/branches/server/monitoring/lnav/lnav']
RESULT(0): "Cloning into '/home/adam/SUSE/OBS/home/aspiers/branches/server/monitoring/lnav/lnav'...\n"
[switch_revision] Starting ...
COMMAND: ['git', 'rev-parse', '--verify', '--quiet', 'origin/sp3']
RESULT(0): '3d19d0865693847c1e1b3b8133faecae155946a9\n'
COMMAND: ['git', 'stash']
RESULT(0): 'Saved working directory and index state WIP on master: 4712bb6 update test for json logs with objects/arrays\n'
COMMAND: ['git', 'reset', '--hard', 'origin/sp3']
RESULT(0): 'HEAD is now at 3d19d08 update to latest ax_cxx_compile_stdcxx.m4\n'
[switch_revision] GIT STASHING
COMMAND: ['git', 'stash', 'pop']

At this point, popping the stash which removed the whole tree failed with conflicts.

OK, so this breakage comes from e822379 in #209.