Adrian Schröter wrote:
On Dienstag, 29. September 2020, 17:59:11 CEST Ludwig Nussel wrote:
I'm trying to build a package from source that uses npm modules. Doing so involves more than one thousand(!) upstream tarballs. In the hope to make that more manageable I wrote a PoC script¹ to produuce a file includable from the spec and to also download the tarballs. Uploading them to OBS as part of the source is rather annoying though as you can't see the forest for all the trees anymore then. So would be convenient if a service like download_files or download_url could do that on server side so the files would be hidden as _service:*
AFAICS services do not have access to previously generated results²
actually they have, your service should be able to find them in .old/ subdir
Ah, so there's an inconsistency. While OBS does that, osc just deletes old files :-( I've filed an issue now¹. So far it's not a special service btw. I thought to use download_files but that one does not process spec file includes. Given the insane amount of sources I feel like editing the spec file directly like done with bundle_gems wouldn't be a good option here. So the next best thing is download_url. That one is extremely basic though so I wanted to make that a bit smarter.
though so would have to download those files on every source change which seems rather wasteful and also takes time. OTOH there's a hack in OBS to have a cache directory for tar_scm³ only.
that is specific implementation to keep scm histories.
Obviously. The question is whether a cache diretory could be made available to other services as well. The /usr/lib/obs/service/*.service file could specify whether a service needs a cache for example. That would remove the need for 'run-service-containerized' to hardcode things based on service name.
So would it be possible to either let services access the previous results or have a cache dir for all? Any other ideas how to handle one thousand source tarballs?
dunno if it matters here, but often you need to postprocess the npm's with random scripts. So you end up in disabled runs there unfortunatly...
So far not. The goal is pristine sources. cu Ludwig [1] https://github.com/openSUSE/osc/issues/845 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org