feat: SGW upg distinction for greenboard + date in schema for all tests#402
Conversation
|
|
||
| Environment variables (required): | ||
| SGW_UPGRADE_RESULTS_FILE — path to the JSONL results file | ||
| SGW_UPGRADE_VERSIONS — comma-separated ordered version list (e.g. "3.1.0,3.2.0,3.3.0") |
There was a problem hiding this comment.
Why not just use regular arguments from the command line? Then their usafe and notes will show up in the generated --help command.
There was a problem hiding this comment.
I did this since upgrade jobs are upgrade jobs by default, they don't need us passing/telling them by CLI that "you're an upgrade job so behave that way when you reach greenboard fixture stage post your test run".
Right? I mean, They ARE upgrade jobs, so they don't need telling. A CLI arg with default value seems redundant.
Plus its kind of a hassle to then skip them and reach the SGW versions specified post them, in the end, to be iterated over.
But if you think that's the best/graceful way, I don't mind implementing it.
There was a problem hiding this comment.
It looks like you've just done the same thing as you described anyway, due to the fact that you have required environment variables. I don't really understand the second half of this paragraph, all I am suggesting is that CLI arguments to this script are more graceful than environment variables. The script itself would behave exactly the same.
| so a final script can upload one combined document per upgrade batch. | ||
|
|
||
| Deferred mode activates when ``SGW_UPGRADE_RESULTS_FILE`` is set in the | ||
| environment. |
There was a problem hiding this comment.
I'd prefer this not be handled by environment variables. You can add command line options at the end of the fixture python source.
| "sgwVersion": target_sgw_version, | ||
| "upgradePath": upgrade_path, | ||
| "failCount": 0 if passed else 1, | ||
| "passCount": 1 if passed else 0, |
There was a problem hiding this comment.
Is this the best way to show this information? How will you know which version failed to upgrade?
There was a problem hiding this comment.
Does greenboard upgrade jobs need showing that as well?
PS : On this note I was also thinking of somehow adding hyperlinks to each bar for the run it relates to, that way each (failing) bar is clickable to the jenkins run and hence a jump to its logs/params/etc
There was a problem hiding this comment.
A bar either entirely red or entirely green seems not too great of a UI experience, is what I am getting at. If they were separate then you'd be able to quickly examine that the upgrade from X to Y failed. At this rate all you have is a binary red or green blob.
There was a problem hiding this comment.
Oh so separate bars for each upgrade iteration. That is a good idea indeed
| # properly set up in config.json (see the schema for that file) | ||
| # and if the --no-result-upload flag is not set on the command line. | ||
| # | ||
| # For upgrade jobs (SGW_UPGRADE_VERSIONS is set), each pytest session |
There was a problem hiding this comment.
This could use some correction since it's not SGW_UPGRADE_VERSIONS anymore (same in other places)
| target_build = sgw_version.build_number | ||
|
|
||
| # Infer upgradeFrom by finding current version in the path | ||
| upgrade_from = "initial" |
There was a problem hiding this comment.
Is there a situation in which you won't find this? Because upgradeFrom == initial doesn't seem meaningful.
2 participants
CBG-5348
The above ticket has a very comprehensive explanation of WHAT and WHY is done in the PR.