Push file to instance with predefined Update Set

[meinzeugde]

It would be helpful to have the option to force a specific update set per file when pushing a file to the instance.

I can imagine to specify this by adding a comment to the file in the first line that contains the sysId of the Update Set or the clear name.

When pushing to the instance, this first line could be parsed out to not be visible in the instance.
On the other hand when pulling a file from the instance, a check is done against the local file to add the comment again to the file after download.

I feel able to implement it myself, but first i want to verify the approach.

[dynamicdan]

Interesting idea. I had also considered a similar "meta-data" approach to identifying update sets or for instance, domains to apply the config to (when using domain separation). I'm not soooo convinced of your use case and I think it's a little error prone. Obviously the sys_id of the update set could be pre-validated to confirm that the update set is for instance still open and abort on error. I would think that over time, there is a risk that the wrong update set might be used if they are not being cleaned up (completed) regularly.

If you want to go forward with this approach then you should make use of the hidden records/.sync_data folder. Each synced file/field has meta data that it can store. This is primarily used to avoid an update collision but it's built in a generic fashion to support saving of multiple meta attributes. Eg, one could save the last "pushed" date and suggest a resync if the date was a long time ago. In your case, I imagine that the user can add a specific meta attribute per comment like:

/* jshint: globals: xyz*/
// SNFS: US: <sys_id>
// SNFS: RefreshXML

function someBusinessRuleOrNormalScriptHere() {
/...
}

Note that linters and other tools also work with comments. Some require that they're the first line in the file so you should handle this case. SNFS = "SN-FileSync". US = Update Set and "RefreshXML" could be an attribute to always refresh the record XML file (that can optionally be saved locally) after every push to the instance. That last one is just an example. This could also help with sync conflicts where the user has resolved a conflict locally (via merge) and wants to confirm that they want the version online to be overwritten.

So I guess you would have a short code that SN-FS picks up on and a functional short code with an optional list of values (comma separated? inclosed in (brackets)? JSON format?). If a function exists to handle the short code then hand it off, if not then ignore the comment. I'm not 100% sure if you want to leave SNFS comments in the field/file or not. I suggest this type of functionality is in a new class/module/file.

Long story short, there are various use cases for this comment meta option although I'm not sure it's the right, zero-human-error approach. I'm happy to see what you come up with!

[meinzeugde]

Wow, didn't expect that much feedback. Now i'm a bit baffled ;)

For now this was just something that i wanted to write down at the right place. Unfortunately the coming weeks i won't really find the time to implement it in the right way. I could hack something down, but that wouldn't be helpful, especially because of your detailed solution approach.

But anyways, thanks for the pleasant feedback. If i find some time looking into it, i definitely will!