Project Update Command Multiple Instances

Ignition
,
#1

Using the new Project Update gateway scripting hook is working to perform Git operations, however I have put this in global as well and and from the logs that the Project Update then fires for every project in the Gateway when you save global.

While not a bad thing, it seems to be killing my git repo as X number of processes try to commit the repo and leaves behind a index.lock file and further commits fail. Any ideas of how to suppress inherited projects from executing the project update script?

#2

Well, I can think of several, though none are perfectly ideal. You could create your own lock file, though I don’t know if any of our first party file functions are guaranteed to be atomic. You could read the project manifest before issuing your git commands - checking for a parent project, I guess.

Is the summary of the issue you’re running into that changing a parent project fires an update script for parent + children, even though children haven’t “really” changed? We’re going to revamp the project update scripts fairly soon, and I’m collecting notes on what to improve.

#3

Its def a new cool venture for us too. Trying to work out a process that works. Right now, we have 10 Ignition environments ans setting up a push to a git branch representing the environment (combination of location and dev/test/prod) to Azure DevOps. Hopefully from there were hoping to do pull requests across branches to do promotions, but haven’t defined that process fully yet. Then once we figure that part out, use Azure pipelines to execute a pull on the target servers when the Pull Request is merged in, essentially fully automating deployments.

Your summary is right, changing a parent project causes the Update to fire on all the children projects. This makes sense from a Ignition execution point of view as the “parent” code has changed, but from a source control perspective only the parent project “changed”. Perhaps split the update or add a flag into the update to be able to know if the change was from the current project or triggers from a parent project update so the commit could be ignored. Perhaps similar to event scripts, the project update script has an event object with more details about the event to be able to use in scripting. This could avoid some of the complexities of doing things like reading the manifest.

2 Likes
#4

Hey @PGriffith, did any of your ideas here get implimented?

#5

Nope, not yet :frowning:
As always, “soon” is a relative term, but they’re still high on our/my backlog, along with a bunch of other scripting related refactors.

#6

HAHA! Oh trust me, I know “soon” all to well. Thanks for the update, no worries! Glad to hear its still on the table.