DevAd development assistant

Scheduled reviews and campaigns

On owner installations that are configured for it, scheduled DevAd runs can review files, prepare proposals and advance queued campaigns. Whether they run depends on your local models, your settings and the run budget you have left. These runs prepare work, and they do not show that DevAd can publish a release on its own.

The larger unit of work is a campaign: one goal in ordinary language, with evidence and a way to know when it is done. DevAd files campaigns itself from the gaps it finds (a defect its own review rated high, a competitor claim that no longer holds, a support report with a reproduction, a release that was refused), and you can file one from the Release desk. A campaign is designed to go through the stages below. Each stage records its result, so check that record before you assume the stage completed:

• Read the code the goal touches and write a plan: which files change, in what order, and which test must fail first.
• Build in a separate copy of the code, never in the copy you are using. The failing test is written first, then the change, then a comment saying why.
• Check everything itself: the tests, the search for names that are used but never defined, the rule that no capability may be removed, the release scan. A summary written by a model does not count as a passing check.
• Review with a different model than the one that built, following a fixed procedure: remove each fix, confirm its test fails without it, then restore the fix.
• Merge in order, and rehearse the result: the whole test suite, the build, the release checks, the pages rendered, the panel started and driven.
• Report what changed, what was measured, and what was left, with the numbers.

A step that fails is retried with another model from your machine before it is given up on. When every retry fails, the campaign stops and files a card that names the step and the reason.

Review and release controls

• It will not merge a change that removes a tool, a route, a fallback or a check. A replacement has to land in the same change and handle the same inputs, or the change stays a proposal.
• It will not settle a merge conflict its rules cannot settle. The campaign is held, and the card names the file and the lines.
• It will not publish a release when any release check fails. The release stays on your disk and the verdict names the reason.
• It will not change the checks that limit what it may do. A proposal that touches them is marked for you and cannot be promoted by DevAd.
• It will not use a paid model unless Allow premium models is on in Settings.
• It will not take a request from anyone but the owner of the copy. The Release desk and its routes refuse every other account.

How to read a report

Open the Release desk panel. Each campaign is one row: the goal, its state (running, done, held), how many stages are done of how many, how long it has taken, and the last piece of evidence it recorded. Read the report opens the report it wrote. It starts with three sections:

Below those, the report lists the evidence it recorded, the acceptance tests with the input each one fails on, and the command that puts every changed file back.

Under the report, What happened lists every recorded step: when, which model or person did it, what it did, the confidence number, and the command that puts that step back. A held campaign says in its row why it is held.

How to ask for a change

In the Release desk, Ask DevAd to build takes the goal in one or two sentences and, if you want, one line per way you will know it is done. Eligible campaigns can advance on a scheduled run. Holds, approvals and the run budget can delay a campaign, and the Release desk shows its recorded state. From the console, /campaign followed by the goal does the same; add -- and how you will know it is done, with a semicolon between several. /campaign on its own lists every request and its state. A copy whose release predates campaigns says Not available on this copy yet in the box; update from the News panel.

The numbers it publishes

Use these commands from the install folder to inspect the available measurements. Check the run date, model and test conditions before comparing results: