Generally everyone agrees that the studio code editor needs to have version control implemented.
Currently some users are working around this, by using the cli tool to export and save to GIT their code changes on uilicious platform.
This thread here is to gather feedback on conflicting future implementation details, and how it would impact the user experience workflow (you).
Also ideally, please give context to your feedback if you are a QA with a strong developer/programming background, or if you are a QA who just started learning about how to do test automation.
Commit History Management
- Auto-commit before every test run.
- Manual GIT commit messages (ie. disabled by default)
Most developers in their localhost IDE, would be used to this flow. This allows them to customise their commit message and changes to be merged.
The downside of this approach, by allowing tests to run - without commits. This would mean that for users who are unaware of this feature. There is no version control (as there is no commits).
It would also mean there is no commit hash for each test run.
On the flip side, by auto committing before every test run. While this ensure no change is lost - The GIT history would be flooded with system generated messages such as “File Changed: Filename.test.js” (or some other suggested format.)
Git Provider Hosting
- Uilicious as a GIT hosting provider (with a valid URL, etc)
- Uilicious as a GIT client / editor
Another issue is that, we are clearly not gonna be a gitlab. And it would be a major scope creep to start implementing git hosting features (branching, merge requests, issue tracking, etc).
Yet from a non technical user point of view, we want to retain the ease of setting up tests, without any git knowledge.
One option, is to internally provide a git hosting URL on the platform by default, with all the commits in the above. Done directly to this.
Letting users handle all the needed merger, or synchronisation with other git providers.
On the flip side is to treat uilicious platform purely as a git client and workspace. Meaning there will be no means of “git clone” from us. And the system will teat the workspace as a local git, until a remote git is configured to be pushed into.