
On Mittwoch, 30. September 2020, 09:13:01 CEST Ludwig Nussel wrote:
Adrian Schröter wrote:
On Mittwoch, 30. September 2020, 08:34:48 CEST Ludwig Nussel wrote:
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¹.
yeah, it is a bit of a question if osc should put files from service side runs or from former runs into .old/ ...
IMHO the later is better, because it avoids duplicate downloads. But it breaks concepts like automatic changelog generation.
How does that work on server side then? Doesn't seem to make sense for osc to behave differently than the server side.
server side run results are always commits, so the problem is not existing there.
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.
well, that will remain as service specific decision...
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 far no service needs a cache, it just can implement one optional. Also it might be a decision of a service to hide content to others. So it makes IMHO not much sense to put this into .service files.
Ok there is no service that strictly *needs* a cache, yet it totally makes sense for tar_scm resp obs_scm. There's no way for a service to communicate that though.
right, since it is anyway an admin decision to run them containerized or not. With or without network.
Extra options for services are hardcoded in 'run-service-containerized'. So it's not a service decision but one that 'run-service-containerized' takes. So what I'm saying is that instead of hardcoding a cache dir for a specific service name in 'run-service-containerized', there could be a way for the service to tell 'run-service-containerized' that it wants a cache. Once such a method is available, any service could leverage a cache if desired.
I do not see an advantage here, any service can make such a thing configurable via /etc/ configs like the existing do. If we add this to .service files we just limit the options here, because it needs to stay compatible for all services IMHO -- Adrian Schroeter <adrian@suse.de> 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org