mirror of https://github.com/abpframework/abp.git
selman koc
7 days ago
committed by
GitHub
GitHub
20 changed files with 1073 additions and 11 deletions
@ -0,0 +1,16 @@ |
|||
<Project Sdk="Microsoft.NET.Sdk"> |
|||
|
|||
<PropertyGroup> |
|||
<OutputType>Exe</OutputType> |
|||
<TargetFramework>net10.0</TargetFramework> |
|||
<ImplicitUsings>enable</ImplicitUsings> |
|||
<Nullable>enable</Nullable> |
|||
<RootNamespace>Volo.Abp.Docs.SyntaxCheck</RootNamespace> |
|||
<AssemblyName>CheckDocsSyntax</AssemblyName> |
|||
</PropertyGroup> |
|||
|
|||
<ItemGroup> |
|||
<PackageReference Include="Scriban" /> |
|||
</ItemGroup> |
|||
|
|||
</Project> |
|||
@ -0,0 +1,347 @@ |
|||
using System.Text.Json; |
|||
using Scriban; |
|||
using Scriban.Runtime; |
|||
using Scriban.Syntax; |
|||
|
|||
// Validates the Scriban template syntax embedded in `docs/en/` Markdown files.
|
|||
//
|
|||
// For each input file we run `Template.Parse` and a strict-mode render with the
|
|||
// same parameter set the docs renderer injects at runtime (each docs-params.json
|
|||
// `<name>` and its `<name>_Value` companion, plus Document_Language_Code,
|
|||
// Document_Version and Release_Status). StrictVariables is enabled on purpose so
|
|||
// references that would otherwise be silently rendered as empty strings surface
|
|||
// as build failures here.
|
|||
//
|
|||
// Known limitations:
|
|||
// - Partial template inlining is not executed: partial bodies are loaded from
|
|||
// external storage at render time, so they cannot be resolved in CI. Files
|
|||
// under `docs/en/` currently have no `//[doc-template]` references; if one is
|
|||
// added later, errors inside the partial body must be reviewed manually.
|
|||
// - Cookie- and query-string-driven parameter overrides are not injected, but
|
|||
// their keys still resolve to empty strings because they layer on top of the
|
|||
// same `<name>` / `<name>_Value` entries that are already injected.
|
|||
|
|||
namespace Volo.Abp.Docs.SyntaxCheck; |
|||
|
|||
internal static class Program |
|||
{ |
|||
private const string DefaultDocsRoot = "docs/en"; |
|||
private const string DocsParamsFileName = "docs-params.json"; |
|||
|
|||
private static readonly string[] BuiltInVariables = |
|||
{ |
|||
"Document_Language_Code", |
|||
"Document_Version", |
|||
"Release_Status" |
|||
}; |
|||
|
|||
public static int Main(string[] args) |
|||
{ |
|||
var useGitHubAnnotations = Environment.GetEnvironmentVariable("GITHUB_ACTIONS") == "true"; |
|||
|
|||
var inputPaths = args.Length == 0 |
|||
? new[] { DefaultDocsRoot } |
|||
: args; |
|||
|
|||
var files = new List<string>(); |
|||
foreach (var path in inputPaths) |
|||
{ |
|||
if (File.Exists(path)) |
|||
{ |
|||
if (path.EndsWith(".md", StringComparison.OrdinalIgnoreCase)) |
|||
{ |
|||
files.Add(Path.GetFullPath(path)); |
|||
} |
|||
} |
|||
else if (Directory.Exists(path)) |
|||
{ |
|||
foreach (var file in Directory.EnumerateFiles(path, "*.md", SearchOption.AllDirectories)) |
|||
{ |
|||
files.Add(Path.GetFullPath(file)); |
|||
} |
|||
} |
|||
else |
|||
{ |
|||
Console.Error.WriteLine($"WARN: path does not exist: {path}"); |
|||
} |
|||
} |
|||
|
|||
if (files.Count == 0) |
|||
{ |
|||
Console.WriteLine("No markdown files to check."); |
|||
return 0; |
|||
} |
|||
|
|||
Dictionary<string, string> renderParameters; |
|||
try |
|||
{ |
|||
renderParameters = BuildRenderParameters(files); |
|||
} |
|||
catch (Exception ex) |
|||
{ |
|||
Console.Error.WriteLine($"ERROR: failed to load docs-params: {ex.Message}"); |
|||
if (useGitHubAnnotations) |
|||
{ |
|||
Console.WriteLine($"::error::docs-params: {EscapeAnnotation(ex.Message)}"); |
|||
} |
|||
return 1; |
|||
} |
|||
|
|||
var errorCount = 0; |
|||
var warningCount = 0; |
|||
var fileIssueCount = 0; |
|||
var repoRoot = TryFindRepoRoot(Directory.GetCurrentDirectory()); |
|||
|
|||
foreach (var file in files) |
|||
{ |
|||
var fileIssues = CheckFile(file, renderParameters); |
|||
if (fileIssues.Count == 0) |
|||
{ |
|||
continue; |
|||
} |
|||
|
|||
fileIssueCount++; |
|||
|
|||
foreach (var issue in fileIssues) |
|||
{ |
|||
if (issue.Severity == IssueSeverity.Error) |
|||
{ |
|||
errorCount++; |
|||
} |
|||
else |
|||
{ |
|||
warningCount++; |
|||
} |
|||
|
|||
var displayPath = repoRoot != null |
|||
? Path.GetRelativePath(repoRoot, file) |
|||
: file; |
|||
|
|||
var severityLabel = issue.Severity == IssueSeverity.Error ? "error" : "warning"; |
|||
|
|||
Console.WriteLine( |
|||
$"{displayPath}:{issue.Line}:{issue.Column}: {severityLabel}: [{issue.Kind}] {issue.Message}"); |
|||
|
|||
if (useGitHubAnnotations) |
|||
{ |
|||
var command = issue.Severity == IssueSeverity.Error ? "error" : "warning"; |
|||
Console.WriteLine( |
|||
$"::{command} file={displayPath},line={issue.Line},col={issue.Column}::" + |
|||
$"{issue.Kind}: {EscapeAnnotation(issue.Message)}"); |
|||
} |
|||
} |
|||
} |
|||
|
|||
Console.WriteLine(); |
|||
Console.WriteLine($"Checked {files.Count} markdown file(s). " + |
|||
$"{fileIssueCount} file(s) with issues, " + |
|||
$"{errorCount} error(s), {warningCount} warning(s)."); |
|||
|
|||
if (errorCount > 0 || warningCount > 0) |
|||
{ |
|||
Console.WriteLine(); |
|||
Console.WriteLine("Tip: wrap inline Scriban-looking text with `{%{{{ ... }}}%}` " + |
|||
"or wrap whole code blocks with `{%{` ... `}%}` to escape Scriban parsing."); |
|||
} |
|||
|
|||
return errorCount > 0 ? 1 : 0; |
|||
} |
|||
|
|||
private static List<Issue> CheckFile(string file, IReadOnlyDictionary<string, string> renderParameters) |
|||
{ |
|||
var issues = new List<Issue>(); |
|||
string content; |
|||
try |
|||
{ |
|||
content = File.ReadAllText(file); |
|||
} |
|||
catch (Exception ex) |
|||
{ |
|||
issues.Add(new Issue("Read", 1, 1, ex.Message, IssueSeverity.Error)); |
|||
return issues; |
|||
} |
|||
|
|||
var template = Template.Parse(content, file); |
|||
|
|||
foreach (var message in template.Messages) |
|||
{ |
|||
var severity = message.Type switch |
|||
{ |
|||
Scriban.Parsing.ParserMessageType.Error => IssueSeverity.Error, |
|||
Scriban.Parsing.ParserMessageType.Warning => IssueSeverity.Warning, |
|||
_ => (IssueSeverity?)null |
|||
}; |
|||
|
|||
if (severity is null) |
|||
{ |
|||
continue; |
|||
} |
|||
|
|||
var kind = severity == IssueSeverity.Error ? "ScribanParseError" : "ScribanParseWarning"; |
|||
|
|||
issues.Add(new Issue( |
|||
kind, |
|||
message.Span.Start.Line + 1, |
|||
message.Span.Start.Column + 1, |
|||
message.Message, |
|||
severity.Value)); |
|||
} |
|||
|
|||
if (template.HasErrors) |
|||
{ |
|||
return issues; |
|||
} |
|||
|
|||
try |
|||
{ |
|||
var context = new TemplateContext |
|||
{ |
|||
StrictVariables = true |
|||
}; |
|||
|
|||
var scriptObject = new ScriptObject(); |
|||
foreach (var entry in renderParameters) |
|||
{ |
|||
scriptObject[entry.Key] = entry.Value; |
|||
} |
|||
|
|||
context.PushGlobal(scriptObject); |
|||
template.Render(context); |
|||
} |
|||
catch (ScriptRuntimeException ex) |
|||
{ |
|||
issues.Add(new Issue( |
|||
"ScribanRenderError", |
|||
ex.Span.Start.Line + 1, |
|||
ex.Span.Start.Column + 1, |
|||
ex.OriginalMessage, |
|||
IssueSeverity.Error)); |
|||
} |
|||
catch (Exception ex) |
|||
{ |
|||
issues.Add(new Issue("ScribanRenderError", 1, 1, ex.Message, IssueSeverity.Error)); |
|||
} |
|||
|
|||
return issues; |
|||
} |
|||
|
|||
private static Dictionary<string, string> BuildRenderParameters(IEnumerable<string> files) |
|||
{ |
|||
// Reproduces the keys the docs renderer places into its parameter
|
|||
// dictionary before rendering a documentation page.
|
|||
var parameters = new Dictionary<string, string>(StringComparer.Ordinal); |
|||
|
|||
foreach (var name in BuiltInVariables) |
|||
{ |
|||
parameters[name] = string.Empty; |
|||
} |
|||
|
|||
foreach (var paramName in DiscoverParameterNames(files)) |
|||
{ |
|||
parameters[paramName] = string.Empty; |
|||
parameters[paramName + "_Value"] = string.Empty; |
|||
} |
|||
|
|||
return parameters; |
|||
} |
|||
|
|||
private static HashSet<string> DiscoverParameterNames(IEnumerable<string> files) |
|||
{ |
|||
var names = new HashSet<string>(StringComparer.Ordinal); |
|||
var visitedDirs = new HashSet<string>(StringComparer.OrdinalIgnoreCase); |
|||
|
|||
foreach (var file in files) |
|||
{ |
|||
var dir = Path.GetDirectoryName(file); |
|||
while (!string.IsNullOrEmpty(dir) && visitedDirs.Add(dir)) |
|||
{ |
|||
var candidate = Path.Combine(dir, DocsParamsFileName); |
|||
if (File.Exists(candidate)) |
|||
{ |
|||
AddNamesFromDocsParamsFile(candidate, names); |
|||
} |
|||
|
|||
var parent = Path.GetDirectoryName(dir); |
|||
if (string.IsNullOrEmpty(parent) || parent == dir) |
|||
{ |
|||
break; |
|||
} |
|||
|
|||
dir = parent; |
|||
} |
|||
} |
|||
|
|||
return names; |
|||
} |
|||
|
|||
private static void AddNamesFromDocsParamsFile(string path, HashSet<string> sink) |
|||
{ |
|||
// A malformed docs-params.json would silently shrink the injected
|
|||
// variable set and turn parameter file regressions into hard-to-debug
|
|||
// "variable not found" errors on otherwise-fine markdown. Surface the
|
|||
// failure directly so the contributor fixes the JSON instead.
|
|||
using var doc = JsonDocument.Parse(File.ReadAllText(path)); |
|||
|
|||
if (!doc.RootElement.TryGetProperty("parameters", out var parameters) || |
|||
parameters.ValueKind != JsonValueKind.Array) |
|||
{ |
|||
throw new InvalidDataException( |
|||
$"{path}: expected a top-level `parameters` array."); |
|||
} |
|||
|
|||
foreach (var parameter in parameters.EnumerateArray()) |
|||
{ |
|||
if (parameter.TryGetProperty("name", out var nameElement) && |
|||
nameElement.ValueKind == JsonValueKind.String) |
|||
{ |
|||
var name = nameElement.GetString(); |
|||
if (!string.IsNullOrWhiteSpace(name)) |
|||
{ |
|||
sink.Add(name); |
|||
} |
|||
} |
|||
} |
|||
} |
|||
|
|||
private static string? TryFindRepoRoot(string startDir) |
|||
{ |
|||
var current = new DirectoryInfo(startDir); |
|||
while (current != null) |
|||
{ |
|||
var gitPath = Path.Combine(current.FullName, ".git"); |
|||
if (Directory.Exists(gitPath) || File.Exists(gitPath)) |
|||
{ |
|||
return current.FullName; |
|||
} |
|||
|
|||
current = current.Parent; |
|||
} |
|||
|
|||
return null; |
|||
} |
|||
|
|||
private static string EscapeAnnotation(string text) |
|||
{ |
|||
// GitHub workflow command escaping. `%` must be encoded first so the
|
|||
// sequences we introduce below are not double-escaped.
|
|||
return text |
|||
.Replace("%", "%25") |
|||
.Replace("\r", "%0D") |
|||
.Replace("\n", "%0A") |
|||
.Replace(":", "%3A") |
|||
.Replace(",", "%2C"); |
|||
} |
|||
|
|||
private enum IssueSeverity |
|||
{ |
|||
Warning, |
|||
Error |
|||
} |
|||
|
|||
private readonly record struct Issue( |
|||
string Kind, |
|||
int Line, |
|||
int Column, |
|||
string Message, |
|||
IssueSeverity Severity); |
|||
} |
|||
@ -0,0 +1,221 @@ |
|||
# Validates Scriban template syntax in PR-changed Markdown files under docs/en/, |
|||
# so escape issues are caught before they reach the published documentation. |
|||
|
|||
name: Check Docs Syntax |
|||
|
|||
on: |
|||
pull_request: |
|||
paths: |
|||
- 'docs/en/**/*.md' |
|||
- 'docs/en/docs-params.json' |
|||
- '.github/scripts/CheckDocsSyntax/**' |
|||
- '.github/workflows/check-docs-syntax.yml' |
|||
|
|||
permissions: |
|||
contents: read |
|||
pull-requests: write |
|||
|
|||
jobs: |
|||
check-scriban-syntax: |
|||
name: Validate Scriban syntax in docs/en |
|||
runs-on: ubuntu-latest |
|||
|
|||
steps: |
|||
- name: Checkout |
|||
uses: actions/checkout@v4 |
|||
|
|||
- name: Setup .NET |
|||
uses: actions/setup-dotnet@v4 |
|||
with: |
|||
dotnet-version: '10.0.x' |
|||
|
|||
- name: Build syntax checker |
|||
run: dotnet build .github/scripts/CheckDocsSyntax/CheckDocsSyntax.csproj -c Release --nologo -v minimal |
|||
|
|||
- name: Get changed markdown files |
|||
id: changed |
|||
uses: actions/github-script@v7 |
|||
with: |
|||
script: | |
|||
const prNumber = context.payload.pull_request.number; |
|||
const changed = []; |
|||
let paramsChanged = false; |
|||
let page = 1; |
|||
while (true) { |
|||
const { data: files } = await github.rest.pulls.listFiles({ |
|||
owner: context.repo.owner, |
|||
repo: context.repo.repo, |
|||
pull_number: prNumber, |
|||
per_page: 100, |
|||
page, |
|||
}); |
|||
const PARAMS_PATH = 'docs/en/docs-params.json'; |
|||
for (const f of files) { |
|||
const isMutation = |
|||
f.status === 'added' || f.status === 'modified' || f.status === 'renamed'; |
|||
if (!isMutation) continue; |
|||
// For renames, GitHub puts the new path in `filename` and the |
|||
// old one in `previous_filename`. Detect docs-params.json on |
|||
// either side so renames into / out of that path still trigger |
|||
// the parameter-file validation path. |
|||
if (f.filename === PARAMS_PATH || f.previous_filename === PARAMS_PATH) { |
|||
paramsChanged = true; |
|||
} |
|||
if (f.filename.startsWith('docs/en/') && f.filename.endsWith('.md')) { |
|||
changed.push(f.filename); |
|||
} |
|||
} |
|||
if (files.length < 100) break; |
|||
page++; |
|||
} |
|||
core.setOutput('files', changed.join('\n')); |
|||
core.setOutput('count', changed.length.toString()); |
|||
core.setOutput('paramsChanged', paramsChanged ? 'true' : 'false'); |
|||
core.info(`Markdown files to check: ${changed.length}`); |
|||
core.info(`docs-params.json changed: ${paramsChanged}`); |
|||
for (const f of changed) { |
|||
core.info(` - ${f}`); |
|||
} |
|||
|
|||
- name: Run syntax checker |
|||
id: checker |
|||
if: steps.changed.outputs.count != '0' || steps.changed.outputs.paramsChanged == 'true' |
|||
env: |
|||
CHANGED_FILES: ${{ steps.changed.outputs.files }} |
|||
PARAMS_CHANGED: ${{ steps.changed.outputs.paramsChanged }} |
|||
run: | |
|||
mapfile -t files <<< "$CHANGED_FILES" |
|||
args=() |
|||
for f in "${files[@]}"; do |
|||
if [ -n "$f" ] && [ -f "$f" ]; then |
|||
args+=("$f") |
|||
fi |
|||
done |
|||
|
|||
if [ ${#args[@]} -eq 0 ]; then |
|||
if [ "$PARAMS_CHANGED" = "true" ] && [ -f "docs/en/index.md" ]; then |
|||
# No markdown changed, but docs-params.json did. Run the checker |
|||
# against a single known-clean page so BuildRenderParameters / |
|||
# docs-params.json parsing actually executes and fails fast on a |
|||
# malformed parameter file. |
|||
echo "docs-params.json changed but no markdown changed; validating params via docs/en/index.md." |
|||
args+=("docs/en/index.md") |
|||
else |
|||
echo "No existing markdown files to check (all changes are deletions)." |
|||
exit 0 |
|||
fi |
|||
fi |
|||
|
|||
# Capture the checker's stdout so a follow-up step can post it as a PR |
|||
# comment when the run fails, while still streaming it to the job log. |
|||
set -o pipefail |
|||
dotnet run --project .github/scripts/CheckDocsSyntax/CheckDocsSyntax.csproj \ |
|||
-c Release --no-build -- "${args[@]}" 2>&1 | tee checker-output.txt |
|||
|
|||
- name: Upsert PR comment on failure |
|||
if: failure() && steps.checker.conclusion == 'failure' |
|||
uses: actions/github-script@v7 |
|||
with: |
|||
script: | |
|||
const fs = require('fs'); |
|||
const MARKER = '<!-- check-docs-syntax-bot -->'; |
|||
const prNumber = context.payload.pull_request.number; |
|||
|
|||
let report = ''; |
|||
try { |
|||
report = fs.readFileSync('checker-output.txt', 'utf8').trim(); |
|||
} catch (e) { |
|||
report = '(checker output was not captured)'; |
|||
} |
|||
|
|||
const runUrl = `${context.serverUrl}/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`; |
|||
const body = [ |
|||
MARKER, |
|||
'### Docs syntax check failed', |
|||
'', |
|||
'The Scriban syntax checker reported issues in the Markdown files this PR changes. Wrap inline Scriban-looking text with `{%{{{ ... }}}%}` or wrap whole code blocks with `{%{` ... `}%}` to keep it from being parsed as a template.', |
|||
'', |
|||
'<details><summary>Checker output</summary>', |
|||
'', |
|||
'```', |
|||
report, |
|||
'```', |
|||
'', |
|||
'</details>', |
|||
'', |
|||
`[Full run log](${runUrl})`, |
|||
].join('\n'); |
|||
|
|||
// Find an existing bot comment to update (idempotent across re-runs). |
|||
let existing = null; |
|||
for (let page = 1; ; page++) { |
|||
const { data } = await github.rest.issues.listComments({ |
|||
owner: context.repo.owner, |
|||
repo: context.repo.repo, |
|||
issue_number: prNumber, |
|||
per_page: 100, |
|||
page, |
|||
}); |
|||
existing = data.find(c => c.body && c.body.startsWith(MARKER)); |
|||
if (existing || data.length < 100) break; |
|||
} |
|||
|
|||
if (existing) { |
|||
await github.rest.issues.updateComment({ |
|||
owner: context.repo.owner, |
|||
repo: context.repo.repo, |
|||
comment_id: existing.id, |
|||
body, |
|||
}); |
|||
core.info(`Updated existing bot comment (#${existing.id}).`); |
|||
} else { |
|||
const { data: created } = await github.rest.issues.createComment({ |
|||
owner: context.repo.owner, |
|||
repo: context.repo.repo, |
|||
issue_number: prNumber, |
|||
body, |
|||
}); |
|||
core.info(`Created bot comment (#${created.id}).`); |
|||
} |
|||
|
|||
- name: Resolve previous failure comment on success |
|||
# Clear any stale failure comment whenever this workflow run is green, |
|||
# even if the syntax checker step was skipped (e.g. when a later |
|||
# commit reverts the earlier failure so no markdown files appear in |
|||
# the PR's net diff). |
|||
if: success() |
|||
uses: actions/github-script@v7 |
|||
with: |
|||
script: | |
|||
const MARKER = '<!-- check-docs-syntax-bot -->'; |
|||
const prNumber = context.payload.pull_request.number; |
|||
|
|||
for (let page = 1; ; page++) { |
|||
const { data } = await github.rest.issues.listComments({ |
|||
owner: context.repo.owner, |
|||
repo: context.repo.repo, |
|||
issue_number: prNumber, |
|||
per_page: 100, |
|||
page, |
|||
}); |
|||
|
|||
const existing = data.find(c => c.body && c.body.startsWith(MARKER)); |
|||
if (existing) { |
|||
const body = [ |
|||
MARKER, |
|||
'### Docs syntax check passed', |
|||
'', |
|||
'The previously reported issues are no longer present in this PR.', |
|||
].join('\n'); |
|||
await github.rest.issues.updateComment({ |
|||
owner: context.repo.owner, |
|||
repo: context.repo.repo, |
|||
comment_id: existing.id, |
|||
body, |
|||
}); |
|||
core.info(`Cleared bot comment (#${existing.id}).`); |
|||
break; |
|||
} |
|||
|
|||
if (data.length < 100) break; |
|||
} |
|||
@ -0,0 +1,226 @@ |
|||
# Introducing ABP Studio AI Agent |
|||
|
|||
The new ABP Studio release introduces a deeply integrated set of features designed around one idea: an AI coding agent that truly understands ABP solutions, sitting inside an IDE that already knows how to build, run, monitor, and iterate on them. |
|||
|
|||
At the center is **ABP Agent**, our AI coding assistant. Around it are long-standing ABP Studio capabilities that have been brought together into a single development loop. Together they turn ABP Studio into a single place where you architect and code your ABP solutions. |
|||
|
|||
 |
|||
|
|||
--- |
|||
|
|||
## Why It Was Needed |
|||
|
|||
General-purpose AI coding tools (Cursor, Claude Code, Windsurf, opencode and similar) are excellent for horizontal, file-shaped work. They read source files, edit them, and run shell commands. That works well for small scripts or front-end apps. |
|||
|
|||
ABP solutions are different. A typical ABP solution is **system-shaped**, not just file-shaped: the important context is not only where files are located, but how modules, layers, permissions, contracts, localization, persistence, and UI pieces work together: |
|||
|
|||
- It is split across multiple modules and layers (Domain, Application, EntityFrameworkCore, HttpApi, Web, etc.) with strict dependency rules. |
|||
- It is composed of many runnable units: HTTP services, gateways, identity servers, background workers, SPAs, mobile apps, plus the Docker containers they depend on. |
|||
- It follows a strong set of conventions: aggregate roots, repositories, application services, DTOs, permissions, localization, event bus, distributed cache, background jobs. |
|||
- It is a *living* system at design time. You don't just read code, you run it, watch logs, follow distributed events, hit HTTP endpoints, and iterate. |
|||
|
|||
A generic agent has none of that vocabulary. It does not know what a module is, which project is the Domain layer, or that an `ApplicationService` should not depend on a `DbContext` directly. It cannot start "the gateway, the auth server, and the two microservices my React app talks to". It just runs `dotnet run` in some folder and hopes. It cannot tell you that the agent's latest edit caused a runtime exception in the Identity service or made the `OrderPlacedEto` event handler silently fail, because it has no concept of "running app". |
|||
|
|||
ABP Agent and the surrounding ABP Studio features were built to close exactly that gap. The agent is born inside an IDE that already understands modules, run profiles, builds, migrations, proxies, Docker containers, Kubernetes services, and distributed runtime telemetry, and it uses every one of them. |
|||
|
|||
--- |
|||
|
|||
## Meet ABP Agent |
|||
|
|||
ABP Agent is the AI coding assistant built into ABP Studio. It operates in three modes, each tuned for a different stage of work: |
|||
|
|||
- **Agent mode**: the implementation mode. The agent reads the solution, writes and edits files, builds the affected projects, runs your apps, watches the runtime, and iterates until the change works end-to-end. |
|||
- **Plan mode**: read-only planning. The agent investigates the codebase, researches the official ABP documentation, and produces a structured implementation plan (Problem, Solution, Workflow Diagram, Files Affected, Expected Result). When you are happy with the plan, a single click promotes it into Agent mode and the implementation starts from the plan. |
|||
- **Ask mode**: read-only Q&A. The agent explains how something works, draws diagrams, and answers questions about your code without touching any files. |
|||
|
|||
The agent is **ABP-aware by default**. It is instructed to prefer ABP base classes over plain POCOs, repositories over direct `DbContext` injection, `ApplicationService` over plain services, the ABP permission system over `[Authorize(Roles=…)]`, localized strings over hardcoded text, `BusinessException`/`UserFriendlyException` over plain `Exception`, the distributed cache abstraction over raw memory cache, and background job abstractions over hand-rolled hosted services. When it is unsure about an ABP feature, it consults the official ABP documentation as a primary source of truth, not random blog posts on the web. |
|||
|
|||
--- |
|||
|
|||
## How ABP Agent Sees Your Application: The Analyze Engine |
|||
|
|||
Before ABP Agent answers anything, it needs to *understand* your solution. This is where the **Analyze** feature does the heavy lifting. |
|||
|
|||
When you open a solution, ABP Studio analyzes every package and builds a structural map: the application's **skeleton**. It identifies what each type actually is in ABP terms: an aggregate root, an entity, a value object, a repository interface or implementation, a domain service, an application service or interface, a DTO, an integration service, a controller, an HTTP API, a background job or worker, an event handler, an ETO, a SignalR hub, a DbContext (EF Core or MongoDB), a permission/feature/setting provider, a global feature, a Mapperly or AutoMapper profile, a fluent validator, a menu contributor, a data seed contributor, an options class, an ABP module with its `[DependsOn]` chain, and many more. |
|||
|
|||
For each of these, the analyzer captures the structural information that actually matters: properties, method signatures with their line ranges, injected dependencies, base classes, the permission groups and items, the feature tree, the settings catalog, the database tables and collections, without parsing C# at runtime. |
|||
|
|||
ABP Agent receives this analyzed skeleton at the start of every session. That means: |
|||
|
|||
- The agent already knows what types exist in each project and what role each one plays, before you ask anything. |
|||
- When you say *"add a Category to my Catalog module"*, the agent already knows where the Domain project is, what the existing aggregate roots look like, which DbContext should get the new entity, where the permissions provider lives, and which application service to extend. |
|||
- When the agent needs to change an existing type, it can fetch a precise outline (base classes, properties, method signatures with exact line ranges) instead of reading thousands of lines of source. That is dramatically faster, dramatically cheaper, and dramatically more accurate. |
|||
- When you modify code, ABP Studio re-analyzes only the affected packages and refreshes the agent's understanding. |
|||
|
|||
This is what we mean by **solution-aware AI**. The agent does not "look at folders and guess"; it works from a typed, ABP-shaped index of your application. |
|||
|
|||
--- |
|||
|
|||
## Native .NET Awareness: No Shell Gymnastics |
|||
|
|||
A common pattern in generic agentic IDEs is to do everything through the terminal. Building? Run `dotnet build` in a shell. Restarting an app? Spawn a process. Adding a migration? More shell. Checking whether the build succeeded? Parse terminal output and pray. |
|||
|
|||
ABP Agent does not work through a terminal for these things. Building, running, restarting, adding migrations, generating proxies, installing client-side libraries: all of these are **first-class operations** the agent invokes directly. Build calls return structured results with errors and warnings the agent can act on immediately. Starting an application returns a structured outcome: which apps started, which failed, and a summarized error log for each failure. There is no string-scraping, no "did the spinner stop yet?" guessing. |
|||
|
|||
The agent also scopes builds intelligently. It can build a single project, a single module, or the entire solution depending on what changed. After editing a few files in your Application layer, it builds just that module (not the whole solution), and only escalates the scope when needed. |
|||
|
|||
--- |
|||
|
|||
## Solution Runner & Live Runtime Monitor |
|||
|
|||
This is the half of ABP Agent that no general-purpose AI IDE can replicate, because no general-purpose AI IDE has a first-class runner for distributed .NET solutions. |
|||
|
|||
**Solution Runner** is the ABP Studio feature that knows about every runnable thing in your solution: web apps, microservices, gateways, identity servers, background workers, CLI applications, mobile and SPA front-ends, plus the Docker containers your stack depends on (databases, caches, message brokers). Apps are grouped into folders and can be launched as a coherent set under a named *run profile*. You start everything with one click; ABP Studio handles ports, dependencies, restart-on-failure, and embedded browser previews. |
|||
|
|||
ABP Agent talks to the Solution Runner directly. It can: |
|||
|
|||
- Start, stop, or restart a specific application, every application inside a folder ("Backend/API"), or all applications. |
|||
- Start or stop Docker containers separately from applications. |
|||
- Run tasks defined in your run profile (database migrations, npm scripts, custom scripts). |
|||
|
|||
When the agent starts an application that crashes on startup, it does not loop forever restarting it. It captures the recent logs from that application, summarizes the failure, returns a structured report to itself, and uses that to **fix the underlying bug in the code** before trying again. |
|||
|
|||
But starting apps is only half of it. The **runtime monitor** is the other half. When your applications run under ABP Studio, the IDE collects, in real time: |
|||
|
|||
- **Exceptions**: type, message, full stack trace, inner exceptions, source application. |
|||
- **Logs**: timestamps, log level, application, message. |
|||
- **HTTP requests**: method, URL, status code, response time. |
|||
- **Distributed events**: name, source, direction (published/received), and payload. |
|||
|
|||
ABP Agent can query all of this. The development loop becomes: |
|||
|
|||
> Generate the code → Build the affected module → Restart the affected application → Hit the endpoint or perform the action → Ask the agent to inspect the last exceptions, the failing HTTP requests, and the distributed events → Fix the bug → Repeat. |
|||
|
|||
That is the loop a generic IDE cannot do, because it cannot see your application after it starts. ABP Agent can. |
|||
|
|||
--- |
|||
|
|||
## Custom Workflows & Task Runner Integration: Determinism When You Need It |
|||
|
|||
LLMs are powerful but non-deterministic. In real teams, some steps must happen **every time** (before or after the agent works) and they must happen in a known order. That is what **Custom Workflows** are for. |
|||
|
|||
A workflow is a named sequence of deterministic steps with a *Before* phase and an *After* phase. You can configure steps such as: |
|||
|
|||
- Build (whole solution, specific modules, or specific packages) |
|||
- Start, stop, or restart applications (specific apps, an entire folder, or all) |
|||
- Start or stop containers |
|||
- Run a Task (any custom task defined in your run profile: `npm install`, custom scripts, code generators, database resets, anything your team already wired into ABP Studio's Task Runner) |
|||
- Add a database migration |
|||
- Install client-side libraries |
|||
- Generate C# or Angular client proxies for HTTP APIs |
|||
|
|||
For example, you can configure a workflow that: |
|||
|
|||
- **Before** the agent works: starts the required containers and runs a code-generation Task. |
|||
- **After** the agent works: builds the affected modules, regenerates client proxies, restarts the gateway and the SPA, and adds a database migration. |
|||
|
|||
Workflows can be **personal** to you, or **shared with your team** through the solution's run profile file, so the deterministic pre/post pipeline travels with the repository and every developer gets the same behavior. |
|||
|
|||
The result is a clean separation: the LLM handles the creative, ambiguous middle (designing the change and writing the code), while your workflow guarantees the boring, must-happen steps around it. The agent becomes more deterministic exactly where determinism matters, without losing flexibility where it doesn't. |
|||
|
|||
The Task Runner integration is what makes the *After* phase especially valuable. You can run absolutely anything as a post-step: npm scripts, custom executables, code generators, integration test runners, lint passes, database refresh scripts. If your team already runs it as part of "I just changed some code, now do X", you can run it automatically after every agent turn. |
|||
|
|||
--- |
|||
|
|||
## Git & GitHub: Reviewing and Committing Without Leaving the IDE |
|||
|
|||
ABP Studio now ships a full Git client with deep GitHub integration. The goal is simple: once the agent finishes a change, you should be able to review, commit, push, branch, and respond to review feedback **without ever leaving ABP Studio**. |
|||
|
|||
The Git side covers everything you'd expect: |
|||
|
|||
- Stage and commit changes with rich, package-grouped change views. |
|||
- Create, switch, and merge branches. |
|||
- Stash and restore work, including a clear flow for stashing before switching branches. |
|||
- View commit history and create branches from any commit. |
|||
- Resolve merge conflicts with a built-in conflict editor. |
|||
- Push, pull, fetch, with seamless OAuth-based GitHub authentication. |
|||
|
|||
On the GitHub side: |
|||
|
|||
- Browse and filter Issues, view their comments, and send an issue (or just its comments) directly to ABP Agent to start working on it. |
|||
- View existing Pull Requests, see their requested changes and comments inline, and send the requested-changes feedback straight into ABP Agent so it can address the reviewer's comments. You can send the feedback into the same session you used to write the change, or start a fresh agent session. |
|||
- A one-click "Create Pull Request" action opens the new-PR page on GitHub directly from the IDE, pre-targeted at the current branch. |
|||
- Jump to any file on GitHub directly from the IDE. |
|||
|
|||
Two AI-assisted touches make this loop especially smooth: |
|||
|
|||
- **AI-generated commit messages.** Click "Generate with AI" and ABP Agent writes a Conventional Commits-style message from the staged diff. Edit it if you want, then commit. |
|||
- **AI Code Review on the diff.** Select the files you want reviewed, run AI review, and inline suggestions stream into the IDE as the analysis runs. Crucially, this is not a generic code review; it is an **ABP-aware** review. The reviewer looks for ABP-specific pattern violations: plain POCOs where ABP base classes belong, direct `DbContext` injection where a repository should be used, hardcoded strings where localization should be used, plain exceptions where `BusinessException` belongs, role-based authorization where ABP Permissions are the right answer, and so on. When the reviewer is unsure, it consults the official ABP documentation before flagging an issue. |
|||
|
|||
The result is a *closed loop*: the agent writes the change, you (or the AI reviewer agent) review the diff, you let the agent fix the comments, you commit with an AI-suggested message, you push, and you head to GitHub for the pull request, all from inside ABP Studio. |
|||
|
|||
--- |
|||
|
|||
## The End-to-End Development Loop |
|||
|
|||
Put the pieces together and ABP Studio becomes the single place where the whole development cycle happens: |
|||
|
|||
1. Open an issue from GitHub, send it to ABP Agent. |
|||
2. Switch to Plan mode; ABP Agent investigates the analyzed solution, consults the ABP docs, produces a structured plan. |
|||
3. Promote the plan to Agent mode. Implementation starts from the plan. |
|||
4. The *Before* workflow runs (start containers, run preparation tasks). |
|||
5. ABP Agent writes the code, batching edits across the affected modules, and fixes any compile errors directly. |
|||
6. The *After* workflow runs (build the affected modules, install client-side libraries, generate proxies, add a database migration, restart the impacted applications). |
|||
7. ABP Agent inspects the runtime monitor (exceptions, logs, HTTP requests, distributed events) and fixes any bug it sees. |
|||
8. You (or the AI reviewer) review the diff. Comments are sent back into the same agent session, or into a new one. |
|||
9. ABP Agent generates a commit message; you commit and push. |
|||
10. Open the new-pull-request page on GitHub with one click from ABP Studio. When reviewers leave requested changes, send them into the same agent session or start a fresh one, and iterate. |
|||
|
|||
You do not need to switch to a terminal to build. You do not need a separate tool to start your microservices. You do not need a different IDE to watch logs. You do not need a separate window for Git and GitHub. **ABP Studio is the only program you use during development, all in one.** |
|||
|
|||
--- |
|||
|
|||
## Learning Over Time |
|||
|
|||
ABP Agent also has a small but powerful feedback feature: when it makes a mistake and you (or the build, or the ABP docs) correct it, it can save that correction as a **lesson**. Lessons are short, verified notes that the agent carries forward into future turns and future sessions, so the same mistake does not happen twice. Over time, the agent gets better at the specific conventions and quirks of *your* solution, not just generic ABP. |
|||
|
|||
--- |
|||
|
|||
## Honest Comparison With Generic AI IDEs |
|||
|
|||
To be fair: Cursor, Claude Code, Windsurf and opencode are excellent products. They have semantic search, plan/agent modes, sub-agents, file editing, and shell access, and we wouldn't dispute any of that. But for ABP development specifically, here is where ABP Agent is genuinely different: |
|||
|
|||
| Capability | ABP Agent | Generic AI IDEs | |
|||
| --- | --- | --- | |
|||
| Aware of ABP roles (aggregate root, app service, repository, DTO, ETO, event handler, etc.) | Yes, structurally indexed | No (flat file/text view) | |
|||
| Knows your solution's modules, layers and dependency rules | Yes | No | |
|||
| Builds with module/package scope as a first-class operation | Yes, structured build result | No, runs `dotnet build` in a shell and parses output | |
|||
| First-class Solution Runner for distributed .NET apps + containers | Yes | No, generic shell processes | |
|||
| Restarting an application, opening its URL, waiting for it to be ready | Yes, built in | No | |
|||
| Live runtime telemetry as a tool: exceptions, logs, HTTP requests, distributed events | Yes | No | |
|||
| ABP-specific patterns checked during AI code review | Yes | Generic patterns only | |
|||
| Pre/post workflows with deterministic build / start / migrate / generate-proxies steps | Yes | No first-class concept | |
|||
| Task Runner integration for arbitrary pre/post steps owned by your team | Yes | No | |
|||
| Adding EF Core migrations as a first-class agent action | Yes | Shell only | |
|||
| Generating C#/Angular client proxies as a first-class agent action | Yes | Shell only | |
|||
| Native ABP documentation as authoritative source for the agent's decisions | Yes | Generic web search | |
|||
| Integrated Git + GitHub (issues, PR viewing, AI review) inside the same window | Yes | Partial / external | |
|||
|
|||
The pattern is consistent: **anything ABP-specific or runtime-specific belongs to ABP Agent and ABP Studio. Anything general-purpose is something everyone has.** That is the line we drew on purpose. |
|||
|
|||
--- |
|||
|
|||
## What This Means For You |
|||
|
|||
If you build with ABP Framework, this release changes how you work in three concrete ways: |
|||
|
|||
1. **You stop describing your solution to the AI.** ABP Agent already knows it. |
|||
2. **You stop bouncing between tools.** Editor, runner, runtime monitor, Git, GitHub, AI review, they all live in one window with one feedback loop. |
|||
3. **You stop accepting non-deterministic side effects.** Custom workflows + Task Runner integration make the boring steps boring again, while the agent focuses on the creative ones. |
|||
|
|||
This is the first release that brings AI assistance to ABP Studio, and we built it so that it is designed *around* the agent rather than bolted on. We think this is the natural shape of AI-assisted enterprise .NET development. |
|||
|
|||
--- |
|||
|
|||
## Short-Term Roadmap |
|||
|
|||
This release is the first step. The features below are already on our short-term roadmap and will land in upcoming releases: |
|||
|
|||
- **Debug Mode**: a dedicated mode where you and ABP Agent co-operate when debugging the solution. The agent can follow breakpoints, inspect state, propose fixes mid-session, and re-run after each change. |
|||
- **Browser control for the agent**: ABP Agent will be able to drive the embedded browser, browse pages, fill forms, and click buttons, so it can verify a UI flow end-to-end on its own and report what it observed. |
|||
- **Custom Workflows improvements**: more step types, richer conditions, finer-grained targets, and better visibility into which workflow ran for which agent turn. |
|||
- **GitHub integration improvements**: in-IDE pull request creation (no more jumping to the GitHub website), richer review handling, and more first-class issue and PR actions for the agent. |
|||
- **Git integration improvements**: more advanced day-to-day Git operations available without leaving the IDE. |
|||
- **Design helper**: ABP Agent will generate images. |
|||
- **Create a new project with the agent**: an AI-driven solution creation flow where you describe the application you want and ABP Agent helps choose the right template, modules, and configuration. |
|||
- **ABP Suite integration**: ABP Agent will be able to invoke ABP Suite for CRUD-page generation. Instead of asking the LLM to write the full set of layers for a CRUD page (which spends a lot of tokens and time), the agent will hand the task to ABP Suite, get a deterministic, production-quality result back, and continue with the parts that actually need the AI. |
|||
|
After Width: | Height: | Size: 52 KiB |
|
After Width: | Height: | Size: 321 KiB |
@ -0,0 +1,8 @@ |
|||
namespace Volo.Abp.BackgroundWorkers; |
|||
|
|||
/// <summary>
|
|||
/// Marks a dynamic background worker manager that supports cron-based scheduling.
|
|||
/// </summary>
|
|||
public interface ISupportsCronScheduling |
|||
{ |
|||
} |
|||
@ -0,0 +1,8 @@ |
|||
namespace Volo.Abp.BackgroundWorkers; |
|||
|
|||
/// <summary>
|
|||
/// Marks a dynamic background worker manager that supports registering workers at runtime.
|
|||
/// </summary>
|
|||
public interface ISupportsRuntimeRegistration |
|||
{ |
|||
} |
|||
@ -0,0 +1,92 @@ |
|||
using System; |
|||
using System.Collections.Immutable; |
|||
using System.Linq; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.Logging; |
|||
using Microsoft.Extensions.Logging.Abstractions; |
|||
using Microsoft.Extensions.Options; |
|||
using OpenIddict.Abstractions; |
|||
using Volo.Abp.DependencyInjection; |
|||
|
|||
namespace Volo.Abp.OpenIddict; |
|||
|
|||
public class AbpDefaultScopesHandler : IAbpOpenIddictClaimsPrincipalHandler, ITransientDependency |
|||
{ |
|||
public ILogger<AbpDefaultScopesHandler> Logger { get; set; } |
|||
= NullLogger<AbpDefaultScopesHandler>.Instance; |
|||
|
|||
public virtual async Task HandleAsync(AbpOpenIddictClaimsPrincipalHandlerContext context) |
|||
{ |
|||
var options = context.ScopeServiceProvider |
|||
.GetRequiredService<IOptions<AbpOpenIddictAspNetCoreOptions>>().Value; |
|||
|
|||
var request = context.OpenIddictRequest; |
|||
if (!IsDefaultScopesEnabled(request, options)) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
if (!context.Principal.GetScopes().IsDefaultOrEmpty) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
var clientId = request.ClientId; |
|||
if (string.IsNullOrEmpty(clientId)) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
var applicationManager = context.ScopeServiceProvider.GetRequiredService<IOpenIddictApplicationManager>(); |
|||
var scopeManager = context.ScopeServiceProvider.GetRequiredService<IOpenIddictScopeManager>(); |
|||
|
|||
var application = await applicationManager.FindByClientIdAsync(clientId); |
|||
if (application == null) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
var permissions = await applicationManager.GetPermissionsAsync(application); |
|||
var prefix = OpenIddictConstants.Permissions.Prefixes.Scope; |
|||
|
|||
var scopes = permissions |
|||
.Where(p => p.StartsWith(prefix, StringComparison.Ordinal)) |
|||
.Select(p => p[prefix.Length..]) |
|||
.ToImmutableArray(); |
|||
|
|||
if (scopes.IsDefaultOrEmpty) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
Logger.LogDebug( |
|||
"Injecting default scopes for client {ClientId} (grant_type {GrantType}): {Scopes}", |
|||
clientId, |
|||
request.GrantType, |
|||
string.Join(", ", scopes)); |
|||
|
|||
context.Principal.SetScopes(scopes); |
|||
context.Principal.SetResources(await scopeManager.ListResourcesAsync(scopes).ToListAsync()); |
|||
} |
|||
|
|||
protected virtual bool IsDefaultScopesEnabled(OpenIddictRequest request, AbpOpenIddictAspNetCoreOptions options) |
|||
{ |
|||
if (request.IsClientCredentialsGrantType()) |
|||
{ |
|||
return options.UseDefaultScopesForClientCredentials; |
|||
} |
|||
|
|||
if (request.IsPasswordGrantType()) |
|||
{ |
|||
return options.UseDefaultScopesForPassword; |
|||
} |
|||
|
|||
if (request.IsTokenExchangeGrantType()) |
|||
{ |
|||
return options.UseDefaultScopesForTokenExchange; |
|||
} |
|||
|
|||
return false; |
|||
} |
|||
} |
|||
Loading…
Reference in new issue