Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Our three project files are 80% the same: same browsers, same suites, same four processes, same timeouts. Every change is a three-file change and one of them always gets missed.
Is there an include or an extends, or is the workspace file the answer?
Accepted answer
No includes, no extends. The one sharing mechanism that carries real weight is defaults.processes in sdods.workspace.yaml:
defaults:
processes:
- { name: pr-check, trigger: pr, tags: "@smoke", browsers: [chromium], harMode: replay, gates: { minPassRate: 100 } }
- { name: nightly-regression, trigger: nightly, tags: "@regression", browsers: [chromium, firefox, webkit], notify: [github] }Those are visible to every project, and a project overrides one by defining the same name. That covers the part you actually change often — the run recipes — and it is one file.
For the rest, keep it explicit per project. A project file that states its own browsers and timeouts is a file you can read on its own and reason about, and the merge rules stay a straight line from defaults to flags. Three files that agree is a smaller problem than an inheritance chain you have to simulate in your head to answer "what will this run do".
If it really is one application, consider whether it should be one project with several modules instead of three projects.
What we do share and would recommend: a repo-root .env for the values every project needs, so credentials are declared once. That layer is read before each project's own files, so a project can still override a name locally.
We also keep shared step definitions and page-object base classes in one package the three projects import. That is where the duplication actually hurt, far more than the yaml did.
Do not share environment files though. Every one we have seen turn into a shared file ended up with if project == x logic smuggled in as variables, and then the base URL for staging depended on which project read the file.
Environments are per project because they describe one deployment of one application.
Practical middle ground we settled on: a small script in CI that diffs the three project files against each other and prints the keys that differ. It does not enforce anything, it just makes the drift visible in the pull request, which turned out to be enough.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.