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
> 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
> AFAICS services do not have access to previously generated results²
actually they have, your service should be able to find them in .old/
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
or from former runs into .old/ ...
IMHO the later is better, because it avoids duplicate downloads. But
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...
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(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org