make vendor tarball name configurable

[johanneskastl]

Tested locally, worked. Please point out any things you find, not sure if I followed all python best practices... :-)

_service file:

<services>
[...]
  <service name="go_modules" mode="disabled">
    <param name="vendorfilename">something-else-than-vendor</param>
  </service>
</services>

[...]
INFO:obs-service-go_modules:Vendor go.mod dependencies to something-else-than-vendor.tar.gz

[dirkmueller]

@johanneskastl please rebase

[johanneskastl]

@johanneskastl please rebase

@dirkmueller Done.

[johanneskastl]

@dirkmueller Flake8 action fails, seems like errors in the .github/workflows/flake8.yml file (unrelated to this PR).

[jfkw]

@johanneskastl Thanks for the PR. Is there a github issue describing the use case for this where we can discuss and document? If not, let's start there. Issue #1 could be one possible related use case, but we haven't decided yet how best to handle multiple occurrences of go.mod.

The vendor archive must unpack (eventually) to vendor/, so having that source file consistently named seemed reasonable until we find counterexamples. If we have one, we can find a way to support it.

In general I would prefer to avoid adding configuration options until we have a use case that has occurrences in multiple upstream Go projects. The goal is to balance the considerations of long-term maintenance of Go application RPM sources in the OBS SCM where bulk source grep (e.g. to find occurrences distro-wide ) and merge (to support any future evolution of the _service definition) are less easy to accomplish than with local Git clones. OBS Source Services do not have visibility into other service instances' configuration parameters, so there is at present a benefit to discoverability / OBS SR reviewers in having the vendor archive name stable.

[johanneskastl]

@johanneskastl Thanks for the PR. Is there a github issue describing the use case for this where we can discuss and document? If not, let's start there. Issue #1 could be one possible related use case, but we haven't decided yet how best to handle multiple occurrences of go.mod.

We recently had a case where kubescape had a submodule, also in go. And one of the ideas was that the go_modules service could be used twice. But in that case the second run overwrote the tarball created by the first one...

https://lists.opensuse.org/archives/list/go@lists.opensuse.org/thread/ZM3SKZLUMCCENO7RIGF63WIHO2BDB5MC/

Not sure if this would have worked, I found another solution.

[dirkmueller]

this should maybe be 'Default: vendor.tar`