How to: Committing project to Git with author and timestamps

I modified the bash script from the best practices guide which has a guide to configuring automatic Git commits on Designer save. I made it so that it adds the author of the change and the timestamp of the change to the commits, and I wanted each resource to be its own commit so it does that too.
The commit is saved under the author as well.
Edit #1: Modified commit comment to use the file saved instead.

image

image

Original guide: Ignition 8 Deployment Best Practices | Inductive Automation

See below!

#!/bin/bash
# this script requires that json library `jq` is installed

# add any new files created to git file tracking
git add .
originalUserName=`git config --list | grep 'user\.name=[\w]*' | sed -e 's/user.name=//g'`

NOW=`date +"%Y-%m-%d %H:%M:%S"`

# find the tracked files that have differences, taking only get their 'resources.json' file
git diff --name-only HEAD | grep -E 'resource.json$' | \
    # ... and loop through each file. Note: what is returned is the relative file path each changed file.
    # This need to be appended onto the working directory held in var $PWD
    while read relFilePath
    do
        # create a variable with the full path of the changed resouce.json file
        filePath="$PWD/$relFilePath"
        folderPath=`echo "$filePath" | sed 's/\/resource.json//g'`
        fileName=`basename "$folderPath"`

        relFilePath_fmt=`echo "$relFilePath" | sed 's/com.inductiveautomation.//g' | sed 's/\/resource.json//g'`       

        # extract out the author of the change and the time using the json library `jq`
        author=`jq -r .attributes.lastModification.actor "$filePath"`
        tstamp=`jq -r .attributes.lastModification.timestamp "$filePath"`
        
        # format the date nicely to put in the commit comment
        tstamp_fmt=`date --date="$tstamp" +"%Y-%m-%d %H:%M:%S"`
        
        git config --global user.name $author
        git commit -m "Modified '$relFilePath_fmt' @ $tstamp_fmt by $author" --date $tstamp -- "$folderPath"
    done

git config --global user.name "Unknown"
# commit everything else that doesn't have a resource.json
git commit -m "Modified resources without resource.json @ $NOW (commit time) - Author could be $author but this is not known"

# push the changes to Git
git push origin master

# set the username back to the original user
git config --global user.name "$originalUserName"
1 Like

Very cool. Soon :tm: we’ve got plans to give the project update script more useful context via parameters, so hopefully a lot of these hacks aren’t necessary.

But I hacked away at piecing together the Bash script for this… :weary: and you know you’re a complete noob at Bash when you run into the old foo = "bar" error :laughing: (can’t have spaces around the =)

Jokes aside, that would be very nice to have! Although I would still want to commit each resource by itself… so I probably still would need some of it

Next thing I need to do is to filter out the resources that were saved but don’t actually have any changes (e.g. Designer saves where you have multiple graphics open but have only made changes to one, but all files get saved)

Our team found that committing on every save caused more headaches than not. Many changes have to be saved to be tested, even if they are broken or we want to revert them a moment later.

We’re still looking for better ways to manage multiple developers contributing to an Ignition project via git, but a big roadblock is all the non-mergeable (binary) items under the projects directory. :frowning:

I know IA was still hoping to convert more of the project files from binary to something text-based. Can anyone on the IA team reading this comment on a timeline for that work?

Can’t provide a timeline, but maybe some insight. What particular resource files are causing issues?
‘Singleton’ resources (project properties, client/gateway event scripts, etc) might happen ~8.2. Vision windows and templates, likely won’t ever happen. Named queries just happened in the last couple releases.

1 Like

I most often bump into alarm pipelines, named queries, and reports in our usage patterns. Glad to hear the named queries is already done.

EDIT: To clarify, those are the binary blobs that we change most often. The times we had conflicts were mostly on named queries, so you guys chose well in hitting that one first. If I had to pick which one we would want next, I would say alarm pipelines.

1 Like