Change 14852
Converted SSTemplateUpdate to work as a trigger of type 'change-content' rather
than 'change-commit', where it has the new responsibility of rejecting the
submit of changelists attempting to update *.cbdsst when the generated stream
specs are rejected by the Helix server (or otherwise fail to update).
The CBD keys are updated if and only the stream spec is accepted by the live
server.
This change removes a common failure mode where *.cbdsst file could be submitted
containing bad content (e.g. syntax errors in the 'Paths:' field), causing the the
corresponding keys not to be updated.
This change introduces a failure mode where the keys could be updated, yet the
changelist containing the *.cbdsst file fails to be submitted, e.g. due to
server crash. Because the server processes changes first before calling the
trigger, the submit is likely to succeed, since things like protections and
required resolves are already checked by the time this script is called. We do
NOT rollback stream spec or keys updates in event of such failure. The assumption
is that the issue with the bogus submit will be addressed quickly.
Several tests performed manually:
* Submit of valid *.cbdsst file. Succeeds.
* Submit of bogus *.cbdsst file. Rejected as expected, with server error
message deliverd with user to help debug it.
* Deletion of jam.cbdsst. Works as expected.
* Recovery of deleted jam.cbdsst. Works as expected.
* Rename of jam.cbdsst to foo (a non-*.cbdsst file). Allows change to
go thru, no keys processing or stream spec update.
* Failed submit of *.cbdsst due to protections change. Works as expected;
handled entirley by p4d.
* Attempted submit of unmodified *.cbdsst in a workspact with SubmitUnchnaged
not set. Works as expected; handled entirley by p4d.
TO DO:
* Add several test cases covering this functionality to the test regression
test suite.
* Update deployment documentation.
* Consider whether we should attempt to rollback keys and stream spec updates
in unlikely event the 'p4 submit' fails. Such a failure is unlikely because,
by the time this script is called, the content s of files are already on the
server, and 'p4d' has already done various checks such as access checks and
resolve-needed checks. Worst case scenario is bad though: stream specs could
get updated without a submit, leading to lack of notificaiton. (This situation
is no worse, and overall much better, than the earlier version.)
than 'change-commit', where it has the new responsibility of rejecting the
submit of changelists attempting to update *.cbdsst when the generated stream
specs are rejected by the Helix server (or otherwise fail to update).
The CBD keys are updated if and only the stream spec is accepted by the live
server.
This change removes a common failure mode where *.cbdsst file could be submitted
containing bad content (e.g. syntax errors in the 'Paths:' field), causing the the
corresponding keys not to be updated.
This change introduces a failure mode where the keys could be updated, yet the
changelist containing the *.cbdsst file fails to be submitted, e.g. due to
server crash. Because the server processes changes first before calling the
trigger, the submit is likely to succeed, since things like protections and
required resolves are already checked by the time this script is called. We do
NOT rollback stream spec or keys updates in event of such failure. The assumption
is that the issue with the bogus submit will be addressed quickly.
Several tests performed manually:
* Submit of valid *.cbdsst file. Succeeds.
* Submit of bogus *.cbdsst file. Rejected as expected, with server error
message deliverd with user to help debug it.
* Deletion of jam.cbdsst. Works as expected.
* Recovery of deleted jam.cbdsst. Works as expected.
* Rename of jam.cbdsst to foo (a non-*.cbdsst file). Allows change to
go thru, no keys processing or stream spec update.
* Failed submit of *.cbdsst due to protections change. Works as expected;
handled entirley by p4d.
* Attempted submit of unmodified *.cbdsst in a workspact with SubmitUnchnaged
not set. Works as expected; handled entirley by p4d.
TO DO:
* Add several test cases covering this functionality to the test regression
test suite.
* Update deployment documentation.
* Consider whether we should attempt to rollback keys and stream spec updates
in unlikely event the 'p4 submit' fails. Such a failure is unlikely because,
by the time this script is called, the content s of files are already on the
server, and 'p4d' has already done various checks such as access checks and
resolve-needed checks. Worst case scenario is bad though: stream specs could
get updated without a submit, leading to lack of notificaiton. (This situation
is no worse, and overall much better, than the earlier version.)