AutoMaxOrganizations, workspaces, projects and modules
The four-level hierarchy AutoMax uses to organise automation across teams and applications.
How organizations, workspaces, projects and modules nest, which file declares each level, what a module adds on top of a features folder, and how the demo project is modelled.
The hierarchy
| Level | Declared in | Holds |
|---|---|---|
| Organization | automax.workspace.yaml → organization | a company or product line; membership roles member, admin, owner |
| Workspace | automax.workspace.yaml → workspaces[] | a team or product area; an organization holds many, and defaultWorkspace names the one projects join unless they set workspace:; defaults for browsers, suites, test-id attribute and shared processes; membership roles viewer, editor, admin |
| Project | projects/<slug>/automax.project.yaml | one application: layers, browsers, environments, data, auth, screenshots, modules, processes |
| Module | modules: inside the project YAML | one functional area: a folder under features/, its testing types, expected tags, owner, Jira component, routes and endpoints |
The workspace file
organization:
slug: automax
name: AutoMax
url: https://github.com/siri1410/AutoMax
workspaces:
- slug: default
name: Default workspace
organization: automax
- slug: platform-qa
name: Platform QA
organization: automax
defaultWorkspace: default
defaults:
browsers: [chromium, firefox, webkit]
suites: [smoke, regression, sanity]
testIdAttribute: data-testid
processes:
- {
name: pr-check,
trigger: pr,
tags: '@smoke',
browsers: [chromium],
harMode: replay,
gates: { minPassRate: 100 },
}Projects inherit defaults and may override any of them. A project joins a workspace with workspace: <slug> (one of workspaces[]); when omitted it joins defaultWorkspace. organization: must match the file's organization. automax workspace tree prints the result, and automax db sync mirrors it into the database so the web UI can show workspaces with each user's effective role.
Modules
organization: automax
workspace: default
modules:
- name: auth
title: Authentication
path: auth # features/auth/ (default: the module name)
layers: [ui]
testingTypes: [functional, smoke, regression, data-driven]
tags: ['@auth']
routes: [login]
- name: inventory
title: Inventory
path: inventory
layers: [ui]
testingTypes: [functional, regression, visual, accessibility]
tags: ['@inventory']
routes: [inventory]
- name: cart
title: Cart
path: cart
layers: [ui]
testingTypes: [functional, regression]
tags: ['@cart']
routes: [cart, checkout]
- name: posts-api
title: Posts API
path: api
layers: [api]
testingTypes: [functional, contract, smoke, regression]
tags: ['@posts']
endpoints: ['/posts', '/posts/{id}', '/posts/{id}/comments']
- name: hybrid
title: Hybrid flows
path: hybrid
layers: [hybrid]
testingTypes: [integration]
tags: ['@hybrid-demo']What a module gives you:
- Lint warns when a scenario under
features/<module>/lacks one of the module's expectedtags. - Coverage joins
routesandendpointswith scenarios per suite tag. - Run selection:
automax run -p demo-shop --module cartruns one module; processes may listmodules:. - Reporting: the dashboard, insights and issues group by module;
jiraComponentandownerflow into created issues.
A module is metadata over a folder. Nothing stops you from starting with the plain features/ui,
features/api, features/hybrid layout and adding modules when a project grows.