Skip to end of metadata
Go to start of metadata


There are two distinct workflows for the Curator in the processing of the proposals:

  1. Validation and Content checking, prepare for Consensus Review
  2. Implement Approved Proposal in master source of truth

Detailed Steps:

Validation and Content checking, push to Consensus Review

  1. Receive email notification of Proposal having been submitted
  2. Click on link and navigate to Jira proposal 
  3. Eyeball for completeness and correctness, general 'sniff test'
    1. If not ok, enter comment and return proposal to Draft state - submitter should get a notification
  4. Create local folder for Proposal Branch for BitBucket for proposals in-flight
    1. create a subfolder for the new proposal under the in-flight folder, name it as proposal ID (like 'UP-64')
    2. from Jira, navigate to branch
    3. click on branch to open it
    4. upper left Clone button second control down to create the copy
    5. open in SourceTree
    6. 'Clone New' if doesn't do this automatically this step downloads the ticket proposal BitBucket branch to new folder for this proposal in the in-flight tree
  5. Update the build label in the utg.xml control file in the in-flight folder
    1. Edit the utg.xml file from the in-flight proposal input folder
    2. Change the label to '<value value="UTG Consensus Review Proposal UP-nn"/>' where 'nn' is the proposal id number
  6. Perform a local build to validate that it is processable
    1. navigate to build tools folder
    2. run 'doBuildBBcrPrep' with argument name of proposal folder created above in step 4
    3. If build fails, find what is causing the error and if in submitted content, comment and return to Submitter.  If error in tools or utg.xml file, debug and fix.
    4. If build succeeds and looks ok, transition ticket to Content Check (click Pass Auto Check)
  7. Commit/Push the validated in-flight image to the remote BitBucket
    1. Check that the SourceTree remote for the git_repo is present in the SourceTree UI
      1. If no entries for the Git Repo in the SourceTree dropdown menu (this may happen if a branch is deleted when return to draft state) then:
      2. open working branch
      3. Settings gear in upper right of the branch window, click to open Settings
      4. Click on Remotes second tab on top bar in Settings window
      5. If no git repo, then click Add
      6. Remote name: git_repo
      7. URL/Path is main UTG git file at https://github.com/HL7/UTG.git
      8. Username: tedmadvocab 
      9. Click ok and verity that the git_repo remote is there and available
    2. do the 'Push' selecting as the source the local repo proposal from the in-flight proposals, destination to the same branch name in the git_repo
  8. Create/Commit new branch for proposal in Git UTG repo with same content(as just pushed to remote BitBucket)
  9. Wait for branch build to complete; check zulip ig builds page at IGBuildStatus 
    1. If build fails, debug and deal with error
  10. Do transition that pastes URL into proposal field - 'Create Branch Rendering' button
  11. Check that the URL is navigable without error
  12. Transition to Consensus Review - 'Passes Manual Content Check' button

Validation and Content checking For Technical Approval proposals

  1. Receive email notification of Proposal having been submitted
  2. Click on link and navigate to Jira proposal 
  3. Eyeball for completeness and correctness, general 'sniff test'
    1. If not ok, enter comment and return proposal to Draft state - submitter should get a notification
  4. Create local folder for Proposal Branch for BitBucket for proposals in-flight
    1. create a subfolder for the new proposal under the in-flight folder, name it as proposal ID (like 'UP-64')
    2. from Jira, navigate to branch
    3. click on branch to open it
    4. upper left Clone button second control down to create the copy
    5. open in SourceTree
    6. 'Clone New' if doesn't do this automatically this step downloads the ticket proposal BitBucket branch to new folder for this proposal in the in-flight tree
  5. Update the build label in the utg.xml control file in the in-flight folder
    1. Edit the utg.xml file from the in-flight proposal input folder
    2. Change the label to '<value value="UTG Technical Correction Proposal UP-nn"/>' where 'nn' is the proposal id number
  6. Perform a local build to validate that it is processable
    1. navigate to build tools folder
    2. run 'doBuildBBcrPrep' with argument name of proposal folder created above in step 4
    3. If build fails, find what is causing the error and if in submitted content, comment and return to Submitter.  If error in tools or utg.xml file, debug and fix.
    4. If build succeeds and looks ok, transition ticket to Content Check (click Pass Auto Check)
  7. Commit/Push the validated in-flight image to the remote BitBucket
    1. Check that the SourceTree remote for the git_repo is present in the SourceTree UI
      1. If no entries for the Git Repo in the SourceTree dropdown menu (this may happen if a branch is deleted when return to draft state) then:
      2. open working branch
      3. Settings gear in upper right of the branch window, click to open Settings
      4. Click on Remotes second tab on top bar in Settings window
      5. If no git repo, then click Add
      6. Remote name: git_repo
      7. URL/Path is main UTG git file at https://github.com/HL7/UTG.git
      8. Username: tedmadvocab 
      9. Click ok and verity that the git_repo remote is there and available
      10. Do a fetch to the ew git repo to populate the git repo branches in Remotes
    2. do the 'Push' selecting as the source the local repo proposal from the in-flight proposals, destination to the same branch name in the git_repo
      1. commit the uncommitted changes (generally the label update for the tug.xml file) by single-click select the branch you are working with
      2. click 'commit' upper left
      3. Stage the utg.xml file, but NOT the cache files
      4. Click 'commit' lower right
      5. make sure in work proposal is selected and Push
        1. Push to repository Origin
        2. select the branch Local branch and same name Remote branch
        3. Track
        4. unselect Master
        5. Push
  8. Create/Commit new branch for proposal in Git UTG repo with same content(as just pushed to remote BitBucket)
    1. Click Push upper left
    2. Push to repository git_repo
    3. Select branch in work, Track checked, unselect Master, and OK
    4. If refs errors, check GitHub and see if branch executes (error may be spurious)
  9. Wait for branch build to complete; check zulip ig builds page at IGBuildStatus 
    1. If build fails, debug and deal with error
  10. Pass Auto check button
  11. Do transition that pastes URL into proposal field - 'Create Branch Rendering' button
  12. Check that the URL is navigable without error
  13. Transition to Sent For Implementation by 'Pass Technical Correction'

Implement Approved Proposal

  1. Overall description of what we will be doing here
    1. Merge the Git branch into the Git master
      1. may need to modify the utg.xml file
      2. may need to adjust others that will be merge conflicts
      3. view the diffs in the branch for utg.xml against the current master in Bitbucket (use bitbucket.hl7.org not in sourcetree) to see if the file in the branch can be trashed or if it must be merged on and element by element basis with the master
      4. Document the change in the history bundle for the changes by creating a new bundle for the approval package (or appending this entry to another in-progress history bundle)
      5. Update the local branch content with the history updates and any resolutions to merge conflict issues
      6. Do a local build to verify that local content is good
      7. Update the Git branch with the updated local content
      8. Them do the merge to the Git master
      9. wait for master git build to complete and check that the version and the changes are in the new published build
      10. remove the Published Example URL value
      11. Look into what needs to happen to remove the built branch in build.fhir.org if the merge does not automagically clean it up
      12. Leave the Bitbucket branch in the ticket (the merge got rid of the mirrored Git branch)
      13. We need to research the proper way to clean up the Bitbucket if needed
      14. Move the proposal to completed in UPSM
      15. Verify that proposal completed looks good in the UP machine
  2. Receive email notification that proposal has been approved and has been queued
  3. Click to navigate to Jira proposal in UPSM machine (different Issue ID)
  4. Transition to enqueue
  5. Check everything ready to merge the branch
    1. Open the UP issue that it is blocked by in a new tab
    2. Check the Published Example
    3. Go to development link (branch or commit) and check the files changed
  6. In the UPSM proposal, click 'apply changes' to begin implementing
  7. Edit the utg.xml <version> and release label for the update
    1. Go to local branch files in 'in-flight' list on local machine
    2. Update the <version> tag to be one higher that the ci build for the build ID
    3. Update the <releaseLabel> in the utg.xml file to be "UTG Process Continuous Integration"
    4. Edit the Special URL properties that have been changed if any have been changed
    5. Create the Provenance entry for this bundle of changes and put it in the local branch in-flight SoT/history folder
      1. In a Terminal window, run script mkPBndHd build# 
      2. run script mkprov for each file in the ticket
      3. edit the json bundle to be correct
      4. copy the new bundle file into the branch/input/SoT/history folder
    6. Fetch the other changes in the git master from the version this branch was build from and the current master
      1. Run SourceTree
      2. Open the branch bookmark
      3. Create a temporary local master working branch (this will be the destination for all the merges and changes in order to not pollute the existing duplicated branches) (add local respository in ST, uncheck also create remote repository)
      4. Open it in ST
      5. Configure both the Bitbucket and GitHub remotes
      6. remote BB:  bitbucket, https://bitbucket.hl7.org/scm/utg/utg.git.  
      7. Fetch all remotes
      8. close bookmark, and open bookmark of branch being worked on
      9. Commit the changes from the local branch to the git branch
      10. Push the local changes from the local branch to the git branch
      11. Close in ST, and open 'applying' bookmark folder in ST
      12. do a Fetch all remotes
      13. double click left pane REMOTES the branch
      14. checkout
      15. double click left pane REMOTES 'master'
      16. checkout rename to 'masterlocal'
      17. verify by 'SHOW' in branches that both are there
      18. double click 'masterlocal' branch local to select it
      19. click Merge
      20. branch to merge into is the top entry the branch name git copy
      21. will usually get merge conflicts will always be the version # of the utg.xml file
      22. Look these over and if only the utg.xml file and the cache files, stage them all and commit - this will update the local files (but not the remote yet)
      23. ./doBuidBBcrPrep applying
      24. check that it builds ok
      25. The Push the changes to the git_repo master
  8. Wait for build to complete of the Git master, and check it looks ok
  9. If build fails, debug and deal with error
  10. Check that rendered update is good
  11. Merge the Git branch into the GIt master
  12. Wait for master build to complete and check it is ok, debug if failure
  13. In the UPSM proposal, click on 'Merge proposal branch into BB'
  14. Update the BitBucket master with the new updated Git Master
  15. Transition ticket to Completed state
  16. Cleanup files
    1. Cleanup 'applying' folder content and branch


Notes from 7/13 experience:

Rework the process.  This is untenable.


Refresh BitBucket master from GitHub master when it is updated

  1. Open SourceTree
    1. Double Click the bookmark BBorgnUpd
  2. Verify have both the git_repo remote and the BB_origin remote present (under Remotes)
    1. If not present, then double-click on bookmark BBornUpd
    2. Go to Settings on upper right
    3. On Remotes on top open and Add new remote for the missing repo
  3. Single-click REMOTES->git_repo→master
  4. Do a Pull (this updates from git_repo:master into the local branch copy)
    1. On the window that opens, 'Pull From Repository' must be git_repo
    2. 'Remote branch to pull' must be 'master'
    3. 'Pull into lock branch' should be git_master
    4. check box commit merged changes immediately
    5. then click OK
    6. (this will update the bookmarked branch link with the git current master)
  5. Then do Push
    1. 'Push to repository' must be 'BB_origin'
    2. checkbox checked from local branch git_master
    3. must change remote branch setting with dropdown to be 'master' (check the little hidden black on blue dropdown to select "master") This is tricky because of screen display sometime. 
    4. checkbox Track? checked
    5. Select All and Push all tags checked
    6. OK
  6. Top line of SourceTree shows all of the branches in sync
  7. If errors, plan some serious time!   



  • No labels