action #93934
closedcoordination #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
0%
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)
Updated by osukup over 3 years ago
- Blocks action #93931: [tools][qem] MTUI support multiple versions of package in incident added
Updated by osukup over 3 years ago
- Blocks action #93937: [tools][qem] qamapi - incidents can have multiple versions packages added
Updated by jbaier_cz over 3 years 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:
- Leave the functionality as is and handle the problem in the tooling
- Update the template metadata section to list versions per product correctly and use this new information in the tooling
Updated by osukup over 3 years 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.1so 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:
- Leave the functionality as is and handle the problem in the tooling
- this will be dirty
- 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 ?
Updated by jbaier_cz over 3 years 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).
Updated by osukup over 3 years 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
Updated by osukup over 3 years ago
- Description updated (diff)
added how new item in template should look
Updated by jbaier_cz over 3 years 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
Updated by jbaier_cz over 3 years 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.
Updated by okurz over 3 years 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.
Updated by jbaier_cz over 3 years ago
If I am not mistaken, poo#93931 depends on this. Luckily, this does not seems like a complicated issue.
Updated by jbaier_cz over 3 years ago
- Status changed from New to Resolved
Implemented in templates-management!61; devel version of MTUI is already using it.