Project

General

Profile

action #93934

coordination #93871: [epic] support process improvement in maintenance requests: packages from different code streams with identical fix sets/features in a single incident

[tools][qem] template generator - multiple package version in incident

Added by osukup about 2 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2020-12-04
Due date:
% Done:

0%

Estimated time:

Description

new incidents can be with more package version

*AC: new line in metadata section of template

PackageVer: 12-SP4(foo=1.2-3.4, bar=1.2-3.4),12-SP5(foo=1.2-4.5,bar=12-4.5,baz=2.3-4.5)


Related issues

Blocks QA - action #93931: [tools][qem] MTUI support multiple versions of package in incidentResolved2021-06-14

Blocks QA - action #93937: [tools][qem] qamapi - incidents can have multiple versions packagesNew2021-06-14

Follows QA - action #80690: [qem] Testing of packages in different codestreams but in one incidentResolved2020-12-03

History

#1 Updated by osukup about 2 months ago

  • Blocks action #93931: [tools][qem] MTUI support multiple versions of package in incident added

#2 Updated by osukup about 2 months ago

  • Blocks action #93937: [tools][qem] qamapi - incidents can have multiple versions packages added

#3 Updated by jbaier_cz about 2 months ago

Current status

This seems not to be an major issue inside template generator. The current version can apparently handle with this in some way. The question remains, if this is the ideal way.

As can be seen in SUSE:Maintenance:19483:242960, the template lists all packages versions inside the Packages: key. There is unfortunately no indication of which version belongs to which product. This is the only difference in such cases.

Packages: sbd = 1.4.1+20200807.883c2f8-3.14.2, sbd = 1.4.1+20200807.883c2f8-6.1, sbd = 1.4.1+20200807.883c2f8-7.1, sbd-devel = 1.4.1+20200807.883c2f8-7.1

The inconsistency check still works, but does the check per product only, so the should be only one version (build number included) of each package per product.

Possible improvement

I can identify two possibilities here:

  1. Leave the functionality as is and handle the problem in the tooling
  2. Update the template metadata section to list versions per product correctly and use this new information in the tooling

#4 Updated by osukup about 2 months ago

jbaier_cz wrote:

Current status

This seems not to be an major issue inside template generator. The current version can apparently handle with this in some way. The question remains, if this is the ideal way.

As can be seen in SUSE:Maintenance:19483:242960, the template lists all packages versions inside the Packages: key. There is unfortunately no indication of which version belongs to which product. This is the only difference in such cases.

Packages: sbd = 1.4.1+20200807.883c2f8-3.14.2, sbd = 1.4.1+20200807.883c2f8-6.1, sbd = 1.4.1+20200807.883c2f8-7.1, sbd-devel = 1.4.1+20200807.883c2f8-7.1

so it means it picked first or last version as valid, because we excepted only one package = version combination per package

The inconsistency check still works, but does the check per product only, so the should be only one version (build number included) of each package per product.

Possible improvement

I can identify two possibilities here:

  1. Leave the functionality as is and handle the problem in the tooling
  • this will be dirty
  1. Update the template metadata section to list versions per product correctly and use this new information in the tooling
  • yes this is the preferred solution

  • there is another thing with template generator -> source.diff for all branches ?

#5 Updated by jbaier_cz about 2 months ago

osukup wrote:

  • yes this is the preferred solution

I agree.

  • there is another thing with template generator -> source.diff for all branches ?

Template generator actually uses osc api -X POST "/request/242960?cmd=diff" to get the source diff, so there is a concatenation of all source diffs inside the template directory (as returned from the OBS).

#6 Updated by osukup about 2 months ago

jbaier_cz wrote:

osukup wrote:

  • yes this is the preferred solution

I agree.

  • there is another thing with template generator -> source.diff for all branches ?

Template generator actually uses osc api -X POST "/request/242960?cmd=diff" to get the source diff, so there is a concatenation of all source diffs inside the template directory (as returned from the OBS).

OH , thx

#7 Updated by okurz about 2 months ago

  • Target version set to future

#8 Updated by osukup about 2 months ago

  • Description updated (diff)

added how new item in template should look

#9 Updated by jbaier_cz about 1 month ago

  • Due date set to 2020-12-04
  • Start date changed from 2021-06-14 to 2020-12-04
  • Follows action #80690: [qem] Testing of packages in different codestreams but in one incident added

#10 Updated by jbaier_cz about 1 month ago

  • Assignee set to jbaier_cz
  • Target version changed from future to Ready

Needs my attention as this is blocking another already "in progress" ticket.

#11 Updated by okurz about 1 month ago

which task would that be that you need this solved for? I don't see a blocked task in our backlog right now.

I understood from hrommel1 that the full support for "multiple package version in incident" would be nice to do but is not seen as critical as the amount of tasks using that approach are limited and workarounds exist.

#12 Updated by jbaier_cz about 1 month ago

If I am not mistaken, poo#93931 depends on this. Luckily, this does not seems like a complicated issue.

#13 Updated by jbaier_cz about 1 month ago

  • Status changed from New to Resolved

Implemented in templates-management!61; devel version of MTUI is already using it.

#14 Updated by cdywan about 1 month ago

  • Due date deleted (2020-12-04)

Also available in: Atom PDF