Add, or consistenly use, a method that can parse the file RELEASE

[bschmalhofer]

I have encountered at least two locations where the file RELEASE is parsed. IMHO there should a dedicated function for that. A dedicated module is probably overkill. Maybe a function in Kernel::System::Main suffices.

Alternatively: Convert RELEASE to JSON or YAML

[bschmalhofer]

A similar thing might apply to parsing the file Kernel/Config.pm .

[svenoe]

I think a method like "Version" in Kernel::System::Main returning program and version is a good idea. Converting to YAML/JSON in principle would be ok, but I guess some people writing external scripts (me^^) would not be happy...

Why or where do you want to parse Kernel/Config.pm?

[bschmalhofer]

@svenoe , Kernel/Config.pm is parsed during the migration. This is problematic because this is Perl code that can be formated in is strange ways.

[svenoe]

But it is probably not done anywhere else, I mean the only reason it is not loaded, is because one OTOBO version has to read out the information of another installation, and I cannot imagine another place where this is necessary. Concerning the parsing itself, it would probably be best, to just eval the complete Load-subroutine (that is basically the "parser") - if you call it, passing a $Dummy (={}) variable, you should be able to just use the DB info directly from that variable, or is it more complicated? (Not so sure...)

[bschmalhofer]

Yes, evaling the method Loadwould be the way to go.

[bschmalhofer]

It might be useful to include the Git branch and the Git commit in the RELEASE file. Either when creating a distribution package or when creating a Docker image. One use case would be in bin/docker/run_test_suite.sh. The name, or the content, of the result file could then include that information.

[bschmalhofer]

So let's go with the method Kernel::System::Main::GetReleaseInfo(). This method parses the file RELEASE and returns the content as a simple hash. The file RELEASE won't be changed.

[bschmalhofer]

TODO:

• test a migration to OTOBO 10.1.x, as GetReleaseInfo() is used in one of the migration modules

[bschmalhofer]

Tests looked fine, even though scripts/test/Selenium/Customer/CustomerTicketAttachment.t had a sporadic error. Testing an actual migration is still TODO.

[bschmalhofer]

Finally, a test migration to OTOBO 10.1.1 has been performed. The version check looked fine. Closing this issue.