Change git password with Visual Studio
We have to update our Windows 10 password every 3 months. I just recently did, so now GIT SYNC does not work with Visual Studio 12. I wanted to change my git password, but see the attached image. There is no way to enter a password. And yeah, this is sort of a VS rather than TC question, but I am using VS for TC code so someone must have experience ;-)
Manually specified file version selector names when uploaded from client via Git
Problem: I upload changes as a commit range in git between a reference branch (master) and my current HEAD. I then later need to rebase my current HEAD against an updated reference branch (master) and re-upload the changes. It cannot be differentiated in the file version selector during a review which versions of the file are reference branch (master) and which are HEAD versions. Generically, client tool uploaded differences from git commit ranges automatically label all versions of files as seen in file version selector drop down, with check-in time and non-human readable git object hash (not commit hash) only. Rebasing changes against the latest version of the reference branch, or merging the latest version of the reference branch into the changes, between a first and second upload to a review causes the "before" version from the reference branch to be different during the second uploaded of files and have a newer timestamp than the "after" version of the file from the first upload. The "before" versions therefore can't be differentiated from the "after" versions in the drop down. Solution: Add optional command line argument for "addgitdiffs" that will allow user specified names to be added to the before and after versions of all files included in the commit range. Conflicting names are automatically appended with standard "(1)", "(2)", etc for a given file based on upload order. For example, if I have changes on a "work" branch that originally forked from "master" branch and changed fileA and fileB, my upload command would be ccollab addgitdiffs --before-name="master" --after-name="work" ask master...work which would upload all changes made on the work branch since it split from master by uploading fileA and fileB from the commit on the master branch right before the work branch split, and fileA and fileB from the head of the work branch (currently). The extra arguments would add labeling for all the files from master as "master" and those coming from the work branch as "work" (new). When my review continues for a while and I need to rebase my work branch against the since-updated master branch I'll need to re-upload my changes relative to the new reference point on the master branch. Running the same command as before accomplishes that but causes a problem. When the differences in fileA are viewed without this feature, what's seen in the file version selector drop down is (larger numbers with the timestamps indicate newer timestamps): "<git object hash> <commit timestamp 1>" <---- from master branch in first upload "<git object hash> <commit timestamp 2>" <---- from work branch in first upload "<git object hash> <commit timestamp 3>" <---- from master branch in second upload "<git object hash> <commit timestamp 4>" <---- from work branch in second upload With the recommended feature this list becomes much more clear: "master <git object hash> <commit timestamp 1>" <---- from master branch in first upload "work <git object hash> <commit timestamp 2>" <---- from work branch in first upload "master(1) <git object hash> <commit timestamp 3>" <---- from master branch in second upload "work(1) <git object hash> <commit timestamp 4>" <---- from work branch in second uploadMatch addgitdiffs commit hash specification in the Command-line client to git commit hash specificat
The addgitdiffs command uses Git commit hash syntax identical to the git tool itself except in one regard: specifying individual commit hashes for addgitdiffs is handled the opposite of how the git tool does it. In Git syntax the following lines are identical: git diff AAAAAAA..BBBBBBB git diff AAAAAAA BBBBBBB In the Collaborator command-line client the following lines have exactly opposite meanings: ccollab addgitdiffs ask AAAAAAA..BBBBBBB ccollab addgitdiffs ask AAAAAAA BBBBBBB This seems to be because the addgitdiffs command handles the second case as a list of individual commits, which it assumes are in reverse chronological order (newest to oldest), rather than a direct pass-thru to the git tool (oldest-first) like the first command. To resolve this, split the addgitdiffs command for specifying a list of commits into a separate command (or require extra options).
TestEngine + Jenkins Plugin: Execute list of Project/Suite/Case SoapUI tests
In their current implementation 1.) the TestEngine needs to be provided a zip with all required files by the calling client 2.) the TestEngine Jenkins plugin will execute one Project/Suite/Case per Jenkins job Problem: This setup does not scale to execute many Project/Suite/Case SoapUI tests in a row Suggestion: ad 1.) a.) Provide TestEngine the ability to access/checkout GIT repos containing SoapUI Projects b.) Add an API to TestEngine that will take the Project/Suite/Case/... parameters and pick all required files from above local checkout area --> Like this no files need to be created/transfered to the TestEngine server What still needs to be done is the specification of the list of Project/Suite/Case to be executed. This could be provided by one or more config files maintained in the GIT repo(s) ad 2.) In case the TestEngine runs on the Jenkins slave(s), the Jenkins job could - checkout the GIT repo(s) - locate the config file(s) containing the list of /Project/Suite/Case SoapUI Tests in the checkout area (e.g. via parameter) - loop the config file(s) calling the TestEngine API with Project/Suite/Case/... parameters --> like this - The TestEngine is running as a server (contrary to testruner.sh) - The invocation of many Project/Suite/Case's will run with minimal overhead (presumably msecs instead of secs) - all required files are taken from a repo -> any updates propagate to TestEngine automatically Remark: This type of automated execution of SoapUI Test from different Project/Suite/Case needs to complemented with a suitable test report (e.g. csv file with Project/Suite/Case/Step, timeStamp, Status, ExecTime, ErrorMsg, ...
