Document toolboxDocument toolbox

Validate Synapse Jira Issues

Owned by Kenneth Daily (Unlicensed)
Last updated: Nov 01, 2024 by Bruce Hoff

Asked to validate a Jira? Here's what you need to know.

Step-by-step guide

Each issue has an “assignee” (usually a Synapse engineer) and a validator (often the person who reported the problem). When the assignee fixes the issue they change the status in Jira to RESOLVED. If the fix is in the back-end (a PLFM issue) or in the web portal (an SWC) issue, then the fix will be available the next week under https://staging.synapse.org. If the issue is fixed in the R client (SYNR) then the fix will be found on the client version on the ‘staging-ran’ RAN. If the fix is in the Python client (SYNPY) then the fix will be found in test.pypi.org at https://test.pypi.org/project/synapseclient/.

  1. The assigned validator should check that the issue is fixed *to their satisfaction*. This ensures there is no disconnect between what the assignee thought it meant to fix the issue and what the validator thought needed to be done.

  2. If the validator feels the issue is fixed, then they change the status in Jira to CLOSED. If they feel it has not been fixed they change the status to OPEN. Either way it helps to add a comment in Jira: If CLOSED, how did you check that the problem was fixed? If OPEN, why do you feel the issue remains?

  3. If an issue is resolved as a "duplicate" of another issue, then it's the responsibility of the person marking the issue as "duplicate" to link the duplicate issue and, in this case, validation is simply acknowledging that the two issues are the same.
  4. If an issue is resolved with the resolution of "Won't Do" or "incomplete", some rationale should be provided and, in this case, validation is acknowledging that the question work will not be done.  If you disagree with the rationale you may reopen the issue.

  5. Once all relevant RESOLVED issues are CLOSED, then the release candidate is sent to production.

For PLFM and SWC issues the fix will be available on https://staging.synapse.org starting Monday or Tuesday after the issue is Resolved. The validator should revisit before the weekly stack release meeting, 3:00PM Friday.

For SYNR issues the fixed version to validate can be obtained by following the instructions under “If you have been asked to validate a release candidate…” here: https://r-docs.synapse.org/

For SYNPY issues the fixed version to validate can be obtained by following the instructions under Validation here: /wiki/spaces/SYNPY/pages/643498030


A note on the use of staging.synapse.org: This instance of Synapse is separate from the production version (synapse.org) with which content is synchronized by the Synapse data migrator.  For example if, in the course of testing a fix or new feature on staging, you create a new project, the project will be removed by the migrator before staging goes live as the new production. This gives validators some latitude to "tinker" on staging, knowing that any changes will be automatically cleaned up. While the two instances of Synapse are largely independent, they do share an underlying S3 bucket: Since the bucket contains hundreds of TB of data, it's not feasible to make a new copy each week.  This means that any operations on staging that change bucket content will not be reverted by the migrator.  Since Synapse treats bucket objects (files) as immutable, most operations don't change bucket content.  The exception is the deletion (as opposed to 'trashing') of an entity by its owner.  If you delete a file or table that you own on staging, it will be permanently deleted.  The web browser only provides trashing of files and tables, so using staging through the browser does not pose a risk.  But using the Python, R or CLI client, and opting to skip the trash can when deleting an entity, does mean that the underlying S3 object will be deleted in production.  Therefore validators should refrain from deleting (without trashing) production data on staging when using the non-browser client to validate Synapse features.