arnoudkooi/sn-scriptsync

"Editing outside VS Code" should be configurable

Blenderpics opened this issue · 12 comments

Hey there!

With 8b25cf1 a change detection was added, that recognises changes made outside of vs code.

The problem with this is that we are checking all files into a git repository for code review purposes and transparency.
If i now switch a branch or merge something, SN-ScriptSync quite happily syncs all files since they were changed.

It would really benefit us if this option could be disabled via a config parameter.

Is this possible?

Sure, Ill add this in a upcoming release!

Hey there!

With 8b25cf1 a change detection was added, that recognises changes made outside of vs code.

The problem with this is that we are checking all files into a git repository for code review purposes and transparency.
If i now switch a branch or merge something, SN-ScriptSync quite happily syncs all files since they were changed.

It would really benefit us if this option could be disabled via a config parameter.

Is this possible?

Can you explain this issue a little bit more? I'm attempting to implement version control using SN-ScriptSync and Gitlab and I'd like to understand the potential issue here. Apologies if this is not the proper place to do this, we can exchange email (I'm not aware of how to direct message in GitHub).

I added a option in 1.9.1 in the settings menu. In my testing after installing it seems the filesystemewatch does not work now, but it reliefs your issue I guess

I added a option in 1.9.1 in the settings menu. In my testing after installing it seems the filesystemewatch does not work now, but it reliefs your issue I guess

Thanks, i will try it out and report back to you.

Hey there!
With 8b25cf1 a change detection was added, that recognises changes made outside of vs code.
The problem with this is that we are checking all files into a git repository for code review purposes and transparency.
If i now switch a branch or merge something, SN-ScriptSync quite happily syncs all files since they were changed.
It would really benefit us if this option could be disabled via a config parameter.
Is this possible?

Can you explain this issue a little bit more? I'm attempting to implement version control using SN-ScriptSync and Gitlab and I'd like to understand the potential issue here. Apologies if this is not the proper place to do this, we can exchange email (I'm not aware of how to direct message in GitHub).

We are a team of 9 developers working on multiple projects. Unfortunately we can't use team development, nor the studio source control. (customer does not allow it.) That's why we are using GitLab in combination with VS-Code and SN-ScriptSync/SN-Utils to at least be able to review our code and to be able to git blame :D. Our workflow looks like this:

  1. Each developer has to switch to the master branch and pull from the origin, before starting with a new story/defect
  2. A new local branch named like the story/defect needs to be created by the developer. It needs to be checked out afterwards.
  3. Each file that will be edited by the developer needs to be downloaded from servicenow by using sn-scriptsync. Even those files that are already present in the developers local filesystem. This is to ensure that the latest version of that file will be edited and not some stale old file. (This would not be necessary if all developers would exclusively work with vs code, since the newest version of each file would be checked into git then. But for variouse reasons we can't guarantee that all developers are working using vs code and our git workflow all the time.)
  4. The developer can then make changes to all files.
  5. Afterwards the developer needs to commit his changes, and push them to our GitLab instance.
  6. The developer needs to create a merge request, which will then be reviewed using a 2 stage code review system.
    We are also using a GitLab CI/CD runner to perform a ESLint validation against our implementation.
    In combination with VS-Code and an ESLint plugin, we can enforce a certain code style, so our code is consistant.
  7. Once reviewed, the merge request will be merged.

What we can't do using this workflow is deploying our scoped application. Each developer (additionally to the git branch) has to create a new update set named like the story/defect he is working on. When we want to deploy our application to the next instance, we create a batch update set parent, and assign all update sets (=> story or defects) to it. We are then deploying the batch update set to the next environment.

The issue we had with the "Editing outside VS Code" feature was that once the developer switches back to the master branch (1.), all his changes he made in his branch where reverted in servicenow. Also the developer might switch branches since he might be working on multiple stories.

Great, thanks! That certainly helps a ton! I'll definitely have to make sure this is toggled off when we roll this out to our developers.

Thanks again!

@arnoudkooi works just fine, thanks!

I added a option in 1.9.1 in the settings menu

Hi - @arnoudkooi could you possibly indicate where this setting is managed? - I'm using v3.0 of sn-scriptsync - I don't see any option in the browser extension "Settings" menu or is this controlled in "settings.json" client side?

This feature was removed, so the option as well

Ah ok - thanks for responding so quickly - does that mean that the point in the original post here is still an "issue"? Would you have any advise about trying to manage the files (client-side) in git and the impact of a user changing branches?

I don't know tbh, maybe Blenderpics can help out?

Thanks - great tool btw

@Blenderpics hi - interesting post above - can I ask if you are still using sn-scriptsync with git for multi-developer access/control? How are you managing on your original post without being able to turn off the client-to-server updates on moving to another branch? Any help gratefully received.