WarningWarning Disclaimer: Currently, the migration from Server to Cloud is already supported by Xray, and we completely advise you to use the following guide: [Jira Cloud Migration Guide]. WarningWarning

 

Questions 

The following questions/issues appear when using the migration script:

  1.  xray_sync* scripts have -export as an optional argument, but should I use it always? For example, pretty much all of the xray_sync* scripts have fileExport.close() on the last line.
    That will fail if I'm not using -export argument since there is no check if -export was even used before it. There are other places in the scripts where there is a check for -export argument, but for some reason, not before the last line.
  2. CustomFields 
    1. GLOBAL_testEnvironmentsId="10806"
      GLOBAL_testType="10000"
      GLOBAL_ManualTestSteps="10104"
      GLOBAL_cucumberTestType="10956"
      GLOBAL_cucumberScenario="10957"
      GLOBAL_genericTestDefinition="10103"
      GLOBAL_preConditionType="10003"
      GLOBAL_preConditionDetails="10110"
      According to the documentation, these IDs are supposed to be got from the on-premise server instance. However, half of these don't exist in our server instance. What should I do with the rest?
  3. Variables
    GLOBAL_statusXray = {
    "PASS": "PASSED",
    "TODO": "TO DO",
    "EXECUTING": "EXECUTING",
    "FAIL": "FAILED",
    "ABORTED": "ABORTED",
    "BLOCKED": "BLOCKED",
    "N/A": "Not applicable"
    }
    GLOBAL_statusStepXray = {
    "PASS": "PASS",
    "TODO": "TODO",
    "EXECUTING": "EXECUTING",
    "FAIL": "FAIL",
    Do need to create the same statuses and status steps to the cloud Xray before running these scripts, or will the scripts somehow do it for me?
    Should I replicate all of the Xray addon configurations from server to cloud and update those to this variables-file before running any scripts?


Answers

  1. In general, you should use -export as that is the safest way to work with the scripts. It will give you as output the issues that have been migrated and therefore provide you a list of issues that you can then use as a "list of issues to ignore" if the script goes down for any reason and you need to re-run it.
    Please note that you are free to introduce in your scripts whatever change you think is best.
  2. The list of fields there is the ones that are generally installed.
    Can you tell me which ones do not appear? There is a bit of dependence on scripts and their fields as such ...it can fail ( e.g GLOBAL_ManualTestSteps this points to the field that holds the manual steps for issues; if you don't have it, the manual scripts import will fail...)
    Just to be clear the id's that are there are just an example; you need to get the ids from your own instance ( Example: for the GLOBAL_ManualTestSteps  you need to get the respective ID from the field "Manual Test Steps" on your instance).
  3. The scripts don't create any configuration; they fill in the blanks in what it regards to the Xray data in Jira issues.  It will not create any new status, so you should try to mimic the best you can in terms of configurations, and those "dictionaries" is a way to try to help users to match the status names ( there are even some you cannot change the names and therefore the need of the mapping).
    Any custom status you have must be created by hand on Cloud; as said, the script will not create any status.
    The only exception is the test environments, and you need to enable "Create Inline Test Environments" to that work as per documentation.








  • No labels