Copied from Controls Software Operations Group's page by Tasha Summers

Working on Dev

PyDM repos are version controlled with Git. See what's available at lcls-dev3.slac.stanford.edu/gitlist (Firefox from development machine only)

Similar to with EDM, first clone the repo. Each subsystem is its own, there is no way to get them all at once

Find which repo you want either by exploring the available repos:

ll $GIT_SITE_TOP/slac/pydm_displays (full list)

ll $PYDM (what you probably want)


If the system you want is simple a repo, follow a standard-ish Git workflow

Either:

git clone $GIT_SITE_TOP/slac/pydm_displays/<subsystem>.git
#When you're done working:
git add <files>
git commit -m "commit message" <files>
git push

Each system's main pages are in their own repo (unlike with EDM where they're all in 'LCLS')

The LCLSHOME main page and system/area ages are in lclshome.git

Make sure to always pull in upstream changes before working, and to use git status and git diff often! Alternatively, you can use the application gitk for a visual view of the repo. You can use git fetch to pull in changes without changing the local files if you'd prefer, but I find it's usually more efficient to go straight to git pull and deal with any merges if there are conflicts.

If you'd prefer to work on feature branches and merge them back into master before pushing that's fine, but it's not a typical workflow here at SLAC. We also don't work on our own forks, or merge things back in with Pull Requests. In trying to make Git work more like CVS, it inevitably results in more conflicts and trouble with deploying across multiple facilities.

OR:

#From your home directory:
eco $PYDM/subsystem

#Copy your files into the checked out repo
cp <files> .

git add <files>
git commit -m "commit message" <files>
git push


If the system you want instead has a link to a 'release' folder then it's been modified to be managed like our IOCs using shell-script wrappers:

eco 
#Then enter the repo you want at the prompt, e.g. pydm-mgnt, then just hit enter at the next prompt to get the master branch

#When you're done making your changes, add the changed files, commit, push, then tag them with a release number
git add <files> 
git commit -m "commit message" <files>
git push

#See a list of existing tags with just git tag or a RELEASE_NOTES file if available
git tag <tagname>
git push --tags

Deploying the updated page(s) on Dev

  • The files you pushed above were checked into the main repo at $GIT_SITE_TOP on Dev = /afs/slac/g/cd/swe/git/repos, but we don't interact directly with those.
  • If using the more typical Git workflow, change to the directory the 'released' version live in, and update the files with the latest versions checked into Git:
    • cd $PYDM/subsystem (subsystem could be event, rf, mgnt, vac, etc.)
    • git status (make sure there's no locally changed files that will cause a conflict - if there is, I suggest making a backup of the locally changed file, then rolling it back with git checkout -- filename)
    • git pull
    • Your changes are now available to everyone else who launches the pages on a Dev machine!
  • If using the eco/cram method, you instead push the version you want from your local working directory
    • After git push --tags, use the 'cram' method:
    • cd ..  (should be in the same level as where the pydm-system, e.g. pydm-mgnt was checked out)
    • eco , then enter the repo you want at the prompt, e.g. pydm-mgnt, then enter the tag number at the next prompt to check out the tagged release
    • cd <tagged-release> 
    • cram ls (see what release version is deployed where)
    • cram push (copies the folder to the different facilities - Dev, FACET, LCLS)
    • cram upgrade -f Dev -n pydm-mgnt <tag>  (changes the 'release' link for that facility to the new tag folder)
    • Your changes are now available to everyone else who launches the pages on a Dev machine!

Deploying the updated page(s) on Prod

  • Deploying the updated page on Prod is almost identical to deploying them on Dev
  • If using the more typical Git workflow, log into a Production machine
    • ssh username@lcls-srv01 (username can be physics or softegr, depending on how your account was set up)
    • cd $PYDM/subsystem  (note the $PYDM variable expands to a different file system on Prod = /usr/local/lcls/tools/pydm/display)
    • git status  (make sure there's no locally changed files that will cause a conflict - if there is, I suggest making a backup of the locally changed file, then rolling it back with git checkout -- filename)
    • git pull (here it will ask for your username's mcclogin password since, for softegr, $GIT_SITE_TOP = ssh://@mcclogin/afs/slac/g/cd/swe/git/repos, i.e. back on mcclogin)
      → no one should be changing the files here, but there will still frequently be local changes. If you need to, just rename the locally changed file and pull your change in, then try to find who changed it locally to let them know what happened.
    • Your changes are now available to everyone else who launches the pages on a Production machine!
  • If using the eco/cram method, you instead update the version you want from your local working directory. Assuming the cram push step was already done (otherwise follow the steps listed in the deploying to Dev section)
    • cram upgrade -f LCLS -n pydm-mgnt <tag>  (changes the 'release' link for that facility to the new tag folder)
    • Your changes are now available to everyone else who launches the pages on a Dev machine!
  • No labels