New branch, is the same as Destine-1025 but with commits squashed
(Bruno: Dani, I'm updating the description of the issue with a check list; it should be ready for you to review it once you are back)
-
code review -
test basic commands -
autosubmit expid (new, and copy) -
archive, unarchive -
delete -
setstatus -
stats -
create -
run -
describe -
refresh -
report -
recovery -
monitor -
updatedescrip -
check
-
-
test documentation examples -
Pay special attention to Splits (ClimateDT workflow) -
Test the 2FA settings (see @larriola's message on de-mwt, but would be helpful to Oriol) -
Test paramiko with proxy jump (related to the message above) -
https://autosubmit.readthedocs.io/en/master/userguide/configure/index.html -
https://autosubmit.readthedocs.io/en/master/userguide/run/index.html#how-to-start-an-experiment-at-a-given-time -
https://autosubmit.readthedocs.io/en/master/userguide/manage/index.html#how-to-clean-the-experiment -
🐛 (see comment) https://autosubmit.readthedocs.io/en/master/userguide/monitor_and_check/index.html -
🐛 (see comment) https://autosubmit.readthedocs.io/en/master/userguide/defining_workflows/index.html#example-2-skippable -
🐛 (see comment) https://autosubmit.readthedocs.io/en/master/userguide/defining_workflows/index.html#example-3-weak-dependencies -
https://autosubmit.readthedocs.io/en/master/userguide/defining_workflows/index.html#loops-definition
-
-
test wrappers -
test ClimateDT experiments -
test testing suite (with the help of @rahme1) -
test API with this version (with the help of @ltenorio) -
note: test too the configuration changes, making sure the API gets the right files
-
-
test the setstatus
+monitor
issue we had in production (question: could it be something with LustreFS? - from issue reported by @nrocha and @kkeller in the production runs) -
test if autosubmit recovery a0py --all -np
andautosubmit recovery a0py --all -np -s
have any chance to cause jobs statuses being set to WAITING (from a comment by @agayayav in the production runs)
Notes to self:
-
test with monitor
(I think some commands have an option to enable that? There is a variablewith_monitor
orto_monitor
, that's not covered and could have a runtime bug)-
any chance this could be related to the production incident with monitor
+setstatus
?
-
-
test a job with filters and no dependencies. The filter is not all and not none (possible runtime bug) -
🐛 setting RETRIALS in a LOCAL project results in a runtime error, while on themaster
it succeeds, see comment
Issues created while reviewing this MR: