Provide changeset-id's in update triggers
Now, the update triggers only provide a path to the workspace being updated.
Having access to the old and new changeset-id's opens up quite a lot new possibilities.
For example, in UE4, when working with plugins in a code project, they are compiled automatically at first. When making code changes to the plugins, they are often not automatically detected which causes the engine to crash at startup.
Deleting two specific folders makes the engine recompile those binaries automatically and thus fixes this inconvenience. Unfortunately, this process takes about 5 minutes on average so doing it after every update is not feasible.
By providing a specific string/tag in the comment of checkins that require a compile, we are able to only recompile when necessary.
In order to make this work, we have to write out the current changeset-id to a file in the before-update trigger. Then in the after update trigger, we get the current one. Finally we would use the find command to get all changesets in between those two and check if any of their comments contain the tag.
We are already able to access the current changeset-id with
cm status --nochanges
and some parsing. (Although this could be made easier.)
Thus, only exposing the future changeset-id in before-update and the previous changeset-id in after-update would suffice.
Thanks in advance
Wouter
shared this idea
-
Wouter
commented
Hi!
There would be a few options how to do this.
The first one would be to add two environment variables:
PLASTIC_INITIAL_CHANGESET: the changeset where the user triggered the update command.
PLASTIC_FINAL_CHANGESET: the changeset the user is at after the update.While this solution is sufficient, it doesn't allow us to know the path of changesets the user took during the update since some of the changeset numbers inbetween those two might be on different branches.
A second and more complete option would be to have an input in the after-update trigger containing the path of changesets the users followed to get to it's current state.
For branches, I assume this path would either follow the current branch until a merge operation allows the switch to the other branch or either go back to the base of the two branches. This option might be a lot harder to implement though. I also made some assumptions about your update process that may be completely wrong and thus make this an unfeasible option.A third option would be to add to the current input <{0}:{1}> an extra variable containing the changeset(s?) that the change is coupled to.
I hope this clears things up :)
-
Hi!
Could you share how the desired input would be so we can have a better understanding? (And save time implementing :P)
