Method and computer program product for automated construction of documents

Abstract

The invention provides a method and a computer program product for automatic construction of documents. The method for document automatic construction comprises the steps that collaborative management is conducted on a document source file and a software source code based on markup language through the same version control system, and the software source code is associated with the document source file; and in response to a submission event of the document source file or the software source code, automatically triggering a document construction process. The document construction process comprises the following steps: analyzing the content of a document source file corresponding to a submission event to generate structured document data; and constructing the structured document data and information extracted from the software source code corresponding to the submission event based on a Sphinx engine to generate a document product. According to the method, the automation of document construction can be realized, and the consistency and maintainability of the document and the code are improved.

Description

Technical Field

[0001] This disclosure relates to methods and computer program products for automating document construction. Background Technology

[0002] As the scale and complexity of software systems, artificial intelligence models, and complex engineering systems continue to grow, technical documentation has become an indispensable and crucial component supporting their research and development, delivery, maintenance, and compliance verification. However, existing mainstream documentation writing and management technologies have shortcomings in areas such as consistency, automation, and collaboration when dealing with large-scale, rapidly iterating engineering practices, severely limiting the effectiveness and quality of documentation. Summary of the Invention

[0003] In one aspect, this application discloses a method for automated document construction, comprising: collaboratively managing markup language-based document source files and software source code using the same version control system, wherein the software source code is associated with the document source file; and automatically triggering a document construction process in response to a commit event of the document source file or software source code. The document construction process includes: parsing the content of the document source file corresponding to the commit event to generate structured document data; and constructing the structured document data and information extracted from the software source code corresponding to the commit event based on the Sphinx engine to generate document artifacts.

[0004] In other respects, this application discloses a non-transitory computer-readable medium storing instructions and a computer program product including instructions. These instructions, when executed by one or more processors, cause the processors to perform the methods described in this application. Attached Figure Description

[0005] When read in conjunction with the accompanying drawings, various aspects of this disclosure are best understood through the following detailed description. It should be noted that, in accordance with standard practice in the art, the features are not drawn to scale. In fact, for clarity of discussion, the dimensions of the features may be arbitrarily increased or decreased.

[0006] Figure 1 This is a flowchart of a method for automated document construction according to an embodiment of the present invention.

[0007] Figure 2 This is a schematic diagram of a trigger control flow for automated document construction according to an embodiment of the present invention.

[0008] Figure 3 This is a flowchart of a method for a document construction process according to an embodiment of the present invention.

[0009] Figure 4This is a schematic diagram of a document construction process according to an embodiment of the present invention.

[0010] Figure 5 This is a schematic diagram of a computing device that can be implemented according to an embodiment of the present invention. Detailed Implementation

[0011] The following disclosure provides numerous different embodiments or examples for implementing various features of the provided subject matter. Specific examples of components and arrangements are described below to simplify this disclosure. Of course, these are merely examples and not limiting.

[0012] Furthermore, the various operations will be described as multiple discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations do not need to be performed in the order presented.

[0013] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly throughout this document. These phrases do not typically refer to the same embodiment; however, they may refer to the same embodiment. Unless the context otherwise specifies, the terms “comprising,” “having,” and “including” are synonyms. The phrases “A or B,” “A and / or B,” and “A / B” mean “(A), (B), or (A and B).”

[0014] As the scale and complexity of software systems, artificial intelligence models, and complex engineering systems continue to grow, technical documentation has become an indispensable and crucial component supporting their research and development, delivery, maintenance, and compliance verification. However, existing mainstream documentation writing and management technologies suffer from numerous systemic flaws in dealing with large-scale, rapidly iterating engineering practices, severely limiting the effectiveness and quality of documentation.

[0015] Specifically, the inventors recognized that current documentation writing and management technologies struggle to guarantee consistency. The fundamental problem lies in the separate management of document content and source code versions, with their development cycles and storage methods disconnected. Whether using word processing software to generate static documents (such as PDFs) or maintaining them through online wiki platforms, document updates are typically independent of the code commit and release process. For example, in teams employing a branching strategy, developers might modify API interfaces on a feature branch, but the corresponding documentation updates might be forgotten or committed separately on the main branch at another time. This results in a blurred or even incorrect version correspondence between documentation and code at the final release. Consequently, documentation content often lags significantly behind the actual functionality of the software, sometimes even leading to contradictions between description and implementation, causing significant confusion and risks for team collaboration, user experience, and subsequent maintenance.

[0016] Furthermore, the inventors recognized a serious deficiency in current document writing and management technologies regarding automation and process integration. On one hand, the processes of updating, validating, and publishing documents heavily rely on manual operations, resulting in low levels of automation. From content format conversion and link verification to final deployment, engineers often need to execute a series of scattered manual commands or clicks, which is inefficient and prone to errors. On the other hand, due to insufficient document structuring capabilities, the content is difficult to parse, validate, and convert into various formats uniformly, making automated processing difficult to implement. For example, traditional Word documents or the proprietary formats of certain Wikis cannot be directly processed by standard toolchains and must undergo cumbersome export and conversion steps. Moreover, this manual process is difficult to deeply integrate with the continuous integration and continuous delivery (CI / CD) processes that are standard in modern software engineering, preventing documents from enjoying the quality and efficiency benefits of automated building, testing, and deployment like code.

[0017] Furthermore, the inventors recognized that current document writing and management technologies have high barriers to entry in terms of collaboration and participation. While powerful document generation frameworks like Sphinx exist, their natively relied-upon reStructuredText (RST) markup language has a complex syntax and a high learning curve. RST's instruction (e.g., directives) and role (e.g., roles) system is obscure for non-specialized documentation engineers, and the complex indentation and formatting requirements easily lead to errors. This creates a technical barrier within development teams, hindering the enthusiasm of developers, testers, and others to directly participate in document writing, making document maintenance a burden for a few experts, and consequently affecting the timeliness, richness, and knowledge sharing of document content.

[0018] In summary, existing technologies have shortcomings in ensuring consistency, achieving automated integration, and improving collaboration friendliness. These deficiencies are interconnected, forming a vicious cycle: high writing barriers lead to low participation, resulting in untimely document updates; the lack of automation amplifies the cost and error rate of manual maintenance. Therefore, the industry needs a solution that can automate the entire process and lower the collaboration barrier.

[0019] The purpose of this invention is to provide an automated document building technology, which aims to lower the threshold for document writing, improve the ability to parse and process document structure, automate the document building, verification and publishing process, and ultimately improve the consistency and maintainability of documents and code.

[0020] Figure 1 This is a flowchart of a method 100 for automated document building according to an embodiment of the present invention. Method 100 can be performed by a system or device for automated document building (e.g., described below). Figure 1In the illustrated embodiment, method 100 may include operations 110 and 120. In other embodiments, the method for automated document construction may include more or fewer or different embodiments. This disclosure is not limiting in this respect.

[0021] At point 110, the same version control system is used to collaboratively manage markup language-based document source files and software source code, where the software source code is associated with the document source files.

[0022] The version control system described in this application serves as a unique and authoritative common repository for both document source files and software source code. This eliminates the clutter of multiple versions of content scattered across various locations, providing a unified version management baseline for both. The version control system can store the complete history of all versions of documents and code, including changes, committers, and time information. This not only provides traceability but also allows for the reconstruction or access to the complete project state (including documents) of a specific version at any point in time. In some embodiments, the version control system utilized can be the Git distributed version control system. Git has a distributed architecture, efficient difference storage, and a powerful branching model; its "commit hash" provides a globally unique identifier for each state change, enabling the association between document and code versions. In some embodiments, the version control system utilized can be other distributed version control systems (e.g., Mercurial (Hg), etc.), centralized version control systems (e.g., Apache Subversion (SVN), etc.), hybrid version control systems (e.g., Perforce Helix Core, etc.), etc., and this disclosure does not impose any limitations in this regard.

[0023] In some embodiments, collaborative management may include recording version changes of document source files and associated software source code in the same commit event. This is not simply requiring documents and code to be stored together, but rather mandating, from a process perspective, that document modifications and code modifications that logically belong to the same change unit be bound together, for example, through a single atomic commit. For instance, software source code and document source files can be stored together in the same version control system repository, thereby leveraging that version control system for collaborative management. Collaborative management not only refers to storing them in the same repository, but more importantly, ensuring that version changes of document source files and associated software source code are recorded in the same commit event. This means that a logically complete update (e.g., fixing a bug and updating the corresponding document) should be saved as a single commit, thus naturally establishing and maintaining a strict correspondence between documents and code in the version history.

[0024] The aforementioned markup language can refer to a lightweight plain text format used for writing document source files. Its syntax is simple, easy for humans to read and write, and can be converted into structured document data. In some embodiments, the aforementioned markup language can be Markdown, including its standard or extended versions, such as CommonMark / GitHub Flavored Markdown, to minimize the barrier to entry for writers. Markdown uses intuitive symbols such as #, -, and ` to define structure, requiring almost no learning curve, and its plain text nature aligns well with version control systems. In some embodiments, the aforementioned markup language can also be reStructuredText (RST), AsciiDoc / AsciiDocFX, Textile, etc. This disclosure does not impose any limitations in this regard.

[0025] At point 120, in response to a commit event to the documentation source file or software source code, the documentation build process is automatically triggered. This operation serves as a bridge between version control and automated builds, ensuring that any changes can immediately initiate the subsequent documentation generation process.

[0026] A commit event is the basic unit for a version control system to record changes to repository content. A commit event represents a change operation on the content managed in the version control system repository. In some embodiments, the content types involved in a commit event include, but are not limited to: document source files, software source code, build configuration files, static resource files, etc. In some embodiments, the change operation types included in a commit event may include: Add (for adding new content); Modify (for updating existing content); Delete (for removing content); or Rename (which can be implemented as a combination of deleting content in the old path and adding content in the new path). In other embodiments, commit events may also include other types of change operations, or other applicable types.

[0027] Specifically, in method 100, the commit event that automatically triggers the document building process can be a change operation on the document source file or software source code. The operation types include, but are not limited to: adding, for adding a new document source file or software source code to the version control system repository; modifying, for updating the content of an existing document source file or software source code in the repository; deleting, for removing a document source file or software source code from the repository; or renaming, for changing the storage path of the document source file or software source code, which can essentially be regarded as deleting content under the old path and adding content under the new path.

[0028] In some embodiments, the documentation build process can be automatically triggered by a Continuous Integration / Continuous Delivery (CI / CD) platform. The CI / CD platform can establish callback mechanisms such as webhooks with its integrated version control system (e.g., Git) to receive specific event notifications from the repository and automatically initiate pipeline tasks when predetermined conditions are met. This integration transforms documentation building from a separate, manual task into a natural, automated step in the software delivery pipeline. In one example, it can be automatically triggered by push events. For example, when a developer executes the `git push` command to synchronize local commits to a specific branch (e.g., `main`, `docs`) in a remote repository, the CI / CD platform captures this event. Direct updates to the main branch typically indicate that the content has passed review and can automatically trigger a build and release to the production environment. In another example, it can be automatically triggered by merge request events. For example, when a merge request (e.g., `PullRequest` or `Merge Request`) is created or updated in the repository, the CI / CD platform captures this event. Previewing the effects of documentation changes during the code review phase can trigger a build and temporarily deploy the generated documentation artifacts to a preview environment for reviewers to verify. In another example, events can be automatically triggered using path-based filtering. For instance, a CI / CD platform can be configured to trigger a task only when the path of a changed file matches a specific pattern. For example, it could trigger only when files in the `docs / ` or `src / ` directories are modified. This optimizes resource consumption and avoids unnecessary documentation builds triggered by changes to irrelevant files (e.g., only modifying `.gitignore`). This automatic triggering can be implemented in several ways. In some embodiments, the CI / CD platform is configured to listen for push events to the main branch, with any push triggering a build process. In other embodiments, the CI / CD platform is configured to trigger only when a commit event involves a path to a documentation source file or software source code, to improve efficiency.

[0029] However, this application is not limited to using a CI / CD platform. In some embodiments, other automated pipeline control modules can be used to automatically trigger the document building process.

[0030] Document artifacts refer to collections of intermediate or final files with specific internal formats generated by the Sphinx build engine during the document build process. These artifacts are the direct output of the build process but have not yet been finally deployed or released, and are typically stored in the local working directory of the build server (e.g., Sphinx's default directories _build / html / , _build / pdf / , etc.). During the build process, the Sphinx engine can generate one or more document artifact formats according to preset configurations, such as collections of HTML website files, PDF files, ePub files, etc. These artifacts are the direct output of the document build process and can be stored locally in the build environment. Subsequently, the release process can be automatically initiated, using deployment tools to upload the HTML artifacts to a static hosting service (such as GitHub Pages) to form online HTML documents; and to upload the PDF and ePub artifacts to a file storage service or attach them to the release, forming downloadable PDF documents and ePub ebooks. This achieves end-to-end automation from source file changes to the availability of multiple document formats.

[0031] Figure 2 This is a schematic diagram of a trigger control flow for automated document construction according to an embodiment of the present invention. The flow details how the control logic for automatically deciding and triggering the document construction process is achieved by listening to submission events and based on intelligent filtering rules.

[0032] like Figure 2 As shown, the process begins with the source files of the documentation and the software source code, which are collaboratively managed through a version control system (e.g., Git). When a developer completes a commit and pushes it to a repository (e.g., a remote repository) or initiates a merge request, the version control system (or its hosting platform), acting as the event source, generates a commit event (e.g., a push event or a merge request event) in real time. This event is then proactively sent to the integrated CI / CD platform via a webhook or similar event push mechanism. Event listeners configured within the CI / CD platform can receive this notification. Upon receiving the event, the CI / CD platform does not immediately trigger a build; instead, it first performs a change path filtering analysis. This analysis retrieves a list of content paths changed by the commit associated with this event and matches them against predefined rules. The "content path list" refers to the storage paths in the repository for all objects that have changed in this commit (including newly added, modified, deleted, or renamed files, directories, etc.). Figure 2As shown in the judgment node, the rule can be set as follows: only when the change involves the content path under the document directory (such as / docs) or the source code directory (such as / src) is it considered a valid build condition (i.e., "document / code change only"). If the condition is met, the CI / CD platform will automatically trigger the downstream document build process; if it is not met, the process will terminate, thereby ensuring the accurate and efficient use of build resources.

[0033] In summary, this trigger control process is based on an "event-driven" architecture, where the version control system proactively notifies changes, and the CI / CD platform is responsible for receiving, filtering, and making decisions on execution. This design achieves deep integration with development activities (push, merge), thereby enabling fully automated document building.

[0034] The design of this trigger control process ensures that the initiation of document build is precise, necessary, and efficient. It seamlessly integrates document build behavior with daily code development activities (commit, push, merge), achieving a fundamental shift from "manual decision-making and execution of builds" to "event-driven automated builds," providing a stable and reliable automated starting point for the entire document automated build system. Subsequent document build processes will be executed after this process is successfully triggered.

[0035] Figure 2 The trigger control flow provided is only an example, and this application may also include other specific trigger control flows, without limitation.

[0036] Figure 3 This is a flowchart of a method 300 for a document building process according to an embodiment of the present invention. Method 300 can be executed by a CI / CD platform by calling appropriate modules (e.g., described below). Figure 3 In the illustrated embodiment, method 300 may include operations 310-320. In other embodiments, the document building process may include more or fewer or different embodiments. This disclosure is not limiting in this respect.

[0037] At point 310, the content of the document source file corresponding to the commit event is parsed to generate structured document data. This parsing can be performed by a parsing module invoked by the CI / CD platform (e.g., the MyST-Parser parser). The content of the document source file corresponding to the commit event that triggered this document building process is parsed and converted into structured document data; for example, the MyST-Parser parser converts Markdown into an abstract syntax tree. MyST-Parser adds support for Sphinx-specific directives and roles (e.g., {directive} and {role}) on top of standard Markdown syntax, enabling Markdown documents to achieve the same powerful expressive capabilities as RST, thus resolving the contradiction between "ease of writing" and "powerful functionality."

[0038] At point 320, the Sphinx engine is used to build structured documentation data and information extracted from the software source code corresponding to the commit event, generating a documentation artifact. This construction can be performed by the Sphinx engine invoked by the CI / CD platform. Based on the Sphinx engine, the aforementioned structured documentation data and information extracted from the software source code corresponding to the same commit event (e.g., application programming interface (API) comments automatically extracted via the sphinx.ext.autodoc extension) are integrated and built. The sphinx.ext.autodoc extension can directly import Python modules, read their docstrings, and automatically generate formatted documentation paragraphs containing function signatures, parameter descriptions, return values, etc. This process is fully automated, ensuring that the API documentation and code declarations are literally identical. This step allows for "integration," merging manually written content from the documentation with automatically generated content from the code, resulting in a unified, internally linked documentation artifact. During this process, the Sphinx engine also automatically handles cross-references within the documentation and to code entities, generates a navigation table of contents and index, and applies styles from the selected theme, ultimately forming a professional, publishable collection of documents.

[0039] In some embodiments, the CI / CD platform executes the document build process by invoking corresponding modules. For example, the CI / CD platform (e.g., Jenkins, GitLab CI, etc.) is configured (e.g., via Webhook) to receive trigger events (e.g., push events or merge request events) from the version control system. When an event occurs, the CI / CD platform automatically creates an isolated execution environment and retrieves the file content of the commit version corresponding to the trigger event. Subsequently, the platform executes predefined build scripts sequentially. These scripts include commands to call a parser to complete parsing, to call the Sphinx engine to complete the integration build, and to call deployment tools to publish the output documentation. Finally, the build status can be fed back to the version control system. For example, the success or failure status of the build will be displayed on the commit history or merge request interface of the Git repository, achieving process observability. Through the above example, end-to-end automated triggering and control of the document build process is achieved.

[0040] In some embodiments, the document building process further includes: performing link validity checks and / or syntax checks on the document source files corresponding to the commit event before parsing. For example, this step is automatically performed by the CI / CD platform using dedicated link checking tools (e.g., Sphinx link checkers such as sphinx-build-blinkcheck) and syntax checking tools (e.g., Markdown format checkers such as markdownlint). The checks may include: verifying the validity of internal and external links in the document; and checking for syntax and style consistency, such as Markdown. The link checker obtains all links, verifies the existence of anchors for internal links, and sends HTTP requests to external links to determine their reachability. The syntax checker checks the text according to a predefined set of rules (e.g., line length, heading format, terminology usage, etc.) to ensure style consistency. This step can act as a quality gate; if the check fails, the building process terminates and error details are fed back to the developer; if the check succeeds, subsequent parsing and building steps are automatically initiated. This approach ensures the basic quality of the document source files and avoids the construction of invalid documents.

[0041] In some embodiments, after generating the document artifacts, the document artifacts are published as output documents. This publication can be performed by the deployment and publishing module invoked by the CI / CD platform, publishing the document artifacts as accessible output documents. In some embodiments, the output documents can be specialized documents with full cross-references, navigation indexes, and search functionality. For example, the document artifacts can be rendered as HTML web pages and deployed to a static website hosting service (e.g., GitHub Pages) for online viewing. The deployment step typically involves using CI / CD scripts to invoke tools (e.g., rsync, scp, or a dedicated publishing action) to upload files in the build directory to a server or cloud storage service and configure the correct HTTP access permissions. In other embodiments, alternatively or additionally, versions in PDF, ePub, or other formats can be generated synchronously during the same build process to meet the needs of offline reading and distribution. The output documents are not limited to the formats mentioned above and can also include documents in other formats such as plain text, LaTeX, XML, and man pages. In the embodiments of this application, a single-format document can be output, or multiple formats such as HTML, PDF, and ePub can be output with one click, greatly improving document quality and user experience.

[0042] Figure 4 This is a schematic diagram of a document construction process according to an embodiment of the present invention. The process specifically illustrates a trigger control flow (e.g., Figure 2 The example shown is a document building process that was successfully started by the trigger control flow shown.

[0043] like Figure 4 As shown, this document building process is a structured, automated processing pipeline that begins with quality checks on the input content and ultimately outputs publishable document artifacts. See below for further details. Figure 4 Describe the main steps involved in the document creation process.

[0044] First, the process performs link validation and syntax checking. This step acts as a quality gate, automatically performing preliminary validation of the document source files corresponding to the commit event. If validation fails, the process terminates and reports an error; if validation passes, it proceeds to the parsing and building phase.

[0045] Subsequently, the process handles two data streams in parallel: structured parsing of document content and automatic extraction of code information.

[0046] Structured parsing of document content can be achieved through in-depth processing of the document source file using a Markdown parsing module. This module can employ enhanced parsers such as MyST-Parser, which not only support standard Markdown syntax for easy writing but also extend support for Sphinx-specific directives (e.g., {directive}) and roles (e.g., {role}). Such parsers can transform plain text document content into precise, machine-readable structured document data. In some embodiments, this data can be represented as an abstract syntax tree, thus fully preserving the document's hierarchical structure, semantic elements, and extended functionality.

[0047] Automatic extraction of code information can be achieved through the sphinx.ext.autodoc extension module, which directly extracts API information from the software source code corresponding to the same commit event. This module can import source code modules, parse their docstrings, and automatically generate formatted document snippets containing detailed information such as function signatures, parameter descriptions, and return values. This process ensures that the API descriptions in the technical documentation are literally consistent with the code implementation.

[0048] Next, the Sphinx build engine receives the results from both processing steps. This engine merges the structured document data (AST) from the documents with automatically extracted API information from the code, and performs the build operation based on the project's configured document themes, navigation structure, cross-reference rules, etc. During this process, the Sphinx engine automatically handles all internal links, generates tables of contents and indexes, and applies a consistent style.

[0049] Finally, the Sphinx build engine outputs documentation artifacts. For example... Figure 4 As shown, a single build can simultaneously generate artifacts in multiple formats, including but not limited to: a complete collection of HTML static website files, formatted PDF document files, and ePub ebook files suitable for e-readers. These document artifacts are the final output of the build process, providing directly distributable, multi-format source materials for subsequent automated publishing processes.

[0050] Figure 4 The defined document building process integrates quality checks, enhanced parsing, automated code information extraction, and a professional document engine to achieve efficient and reliable conversion from collaboratively managed source files to high-quality, multi-format, and content-consistent document products.

[0051] In summary, the technical solution provided in this application systematically addresses the core shortcomings of existing document technologies in terms of consistency, automation, and collaboration friendliness through deep integration of collaborative version management, event-driven automation, a low-barrier collaborative toolchain, and a professional document engine. It not only transforms document engineering into an efficient, reliable, and traceable automated process but also seamlessly integrates it into the modern software development lifecycle, thereby significantly improving the overall quality, utility, and maintainability of technical documentation and providing crucial document infrastructure support for large-scale, rapidly iterating, and complex software projects.

[0052] Figure 5 This is a schematic diagram of a computing device that can be implemented according to embodiments of the present invention, and can be used to implement the system or device for automated document construction described above. For example... Figure 5 As shown, computing device 500 may include bus 502 or other communication mechanism for transmitting information, and one or more hardware processors 504 coupled to bus 502 for processing information. The one or more hardware processors 504 may include, for example, one or more general-purpose microprocessors.

[0053] like Figure 5 As shown, in some embodiments, computing device 500 may further include main memory 506 coupled to bus 502. Main memory 506 is used to store information and instructions executed by one or more processors 504, such as random access memory (RAM), cache, and / or other dynamic storage devices. Main memory 506 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by one or more processors 504. These instructions, when stored in storage media accessible to one or more processors 504, can cause computing device 500 to become a dedicated machine customized to perform the operations specified in the instructions. Storage device 508 may include non-volatile and / or volatile storage media. Non-volatile storage media may include, for example, optical discs or magnetic disks. Volatile storage media may include dynamic memory. Common forms of storage media may include, for example, floppy disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, DRAM, PROM, and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, or their networking versions.

[0054] like Figure 5As shown, in some embodiments, computing device 500 may further include one or more communication interfaces or network interfaces 510 coupled to bus 502. Network interface 510 may provide bidirectional data communication coupling to one or more network links connected to one or more networks. As another example, network interface 510 may be a local area network (LAN) card to provide data communication connectivity to a LAN-compatible (or WAN component communicating with a WAN) network. Wireless links may also be implemented.

[0055] Each of the processes, methods, and algorithms described in the preceding sections may be embodied in code modules executed by one or more computer systems or computer processors including computer hardware, and may be fully or partially automated by these code modules. The processes and algorithms may be implemented, partially or fully, in dedicated circuit systems.

[0056] When the functions disclosed herein are implemented as software functional units and sold or used as stand-alone products, they may be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, may be embodied in the form of a software product. The software product may be stored in a storage medium and includes several instructions that cause a computing device (which may be a personal computer, server, network device, etc.) to perform all or some steps of the methods of the embodiments of this application. The storage medium may include a flash drive, portable hard disk drive, ROM, RAM, magnetic disk, optical disk, other media operable to store program code, or any combination thereof.

[0057] Specific embodiments further provide a system including a processor and a non-transitory computer-readable storage medium storing instructions executable by the processor to cause the system to perform operations corresponding to steps in any method of the embodiments disclosed above. Specific embodiments further provide a non-transitory computer-readable storage medium storing instructions executable by one or more processors to cause the one or more processors to perform operations corresponding to steps in any method of the embodiments disclosed above.

[0058] The embodiments disclosed herein can be implemented via a cloud platform, server, or server cluster (collectively referred to below as the "Service System") that interacts with a client. The client can be a terminal device or a client registered by a user at the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can have the platform application installed.

[0059] The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Additionally, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and their associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in an order other than that specifically disclosed, or multiple blocks or states may be combined into a single block or state. Example blocks or states may be executed sequentially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The exemplary systems and components described herein may be configured differently than described. For example, components may be added to, removed from, or rearranged compared to the disclosed example embodiments.

[0060] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. The algorithm may be included in program code or instructions stored in memory (e.g., the aforementioned non-transitory computer-readable storage medium). This algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not explicitly refer to the computer as performing the function but may learn from training data to generate a predictive model of the function.

[0061] The various operations of the exemplary methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, these processors can constitute an engine of processor implementation that operates to perform one or more of the operations or functions described herein.

[0062] Similarly, the methods described herein may be implemented at least in part by a processor, wherein one or more specific processors are instances of hardware. For example, at least some operations of the methods may be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors may also be operable to support the execution of relevant operations in a “cloud computing” environment or as the execution of relevant operations in a “Software as a Service” (SaaS) context. For example, at least some operations may be performed by a group of computers (as an example of a machine containing processors), wherein these operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0063] The execution of certain operations can be distributed across processors rather than residing within a single machine, and can be deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0064] Throughout this specification, multiple instances may be implemented as components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of these individual operations may be performed simultaneously, and not necessarily in the order illustrated. Structures and functions presented as separate components in the example configuration may be implemented as composite structures or components. Similarly, structures and functions presented as single components may be implemented as single components. These and other variations, modifications, additions, and improvements fall within the scope of this document.

[0065] As used herein, "or" is inclusive rather than exclusive unless explicitly indicated by the context. Therefore, in this document, "A, B, or C" means "A, B, A and B, A and C, B and C, or A, B, and C" unless explicitly indicated by the context. Furthermore, "and" is combined and separate unless explicitly indicated by the context. Therefore, in this document, "A and B" means "A and B, combined or separate" unless explicitly indicated by the context. Additionally, multiple instances of resources, operations, or structures described herein may be provided as a single instance. Furthermore, the boundaries between various resources, operations, engines, and data storage devices are somewhat arbitrary and specific operations are illustrated within the context of a particular illustrative configuration. Other functional assignments are foreseeable and fall within the scope of various embodiments of this disclosure. Generally, structures and functions presented as individual resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as single resources. These and other changes, modifications, additions, and improvements fall within the scope of the embodiments of this disclosure as expressed in the appended claims. Therefore, this specification and drawings should be considered illustrative rather than restrictive.

[0066] The terms “comprising” or “including” are used to indicate the presence of a subsequently claimed feature, but do not preclude the addition of other features. Unless otherwise specifically stated or otherwise understood in the context in which they are used, conditional language such as “may,” “can,” “may,” and “can” is generally intended to convey that certain embodiments include certain features, components, and / or steps that are not included in other embodiments. Therefore, this conditional language is generally not intended to imply that one or more embodiments require features, components, and / or steps in any way, or that one or more embodiments must include logic for determining whether such features, components, and / or steps are included in or performed in any particular embodiment, with or without user input or prompts.

[0067] Although the general outline of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broad scope of embodiments of this disclosure. Where more than one embodiment is disclosed, these embodiments of the subject matter may be referred to individually or collectively herein as the term "invention," this is for convenience only and is not intended to automatically limit the scope of this application to any single disclosure or concept.

[0068] The embodiments illustrated herein are described in detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Therefore, “implementation” is not intended to be limiting, and the scope of the various embodiments is defined only by the appended claims and their full scope.

Claims

1. A method for automated document construction, characterized in that, The method includes: Collaborative management of markup language-based document source files and software source code is achieved using the same version control system, wherein the software source code is associated with the document source files; and In response to a submission event to the document source file or the software source code, a document building process is automatically triggered, the document building process including: Parse the contents of the document source file corresponding to the submission event to generate structured document data; and The Sphinx engine is used to construct the structured document data and information extracted from the software source code corresponding to the commit event to generate the document artifacts.

2. The method according to claim 1, characterized in that, The collaborative management includes recording version changes of the document source file and version changes of the associated software source code in the same commit event.

3. The method according to claim 1, characterized in that, The automatic triggering includes: the continuous integration / continuous delivery platform automatically triggering the document building process by listening for push events or merge request events to the version control system.

4. The method according to claim 3, characterized in that, The continuous integration / continuous delivery platform completes the document building process by calling the corresponding modules.

5. The method according to claim 1, characterized in that, The document building process also includes: Before the parsing, the document source file is subjected to link validity checks and syntax standardization checks; If the verification or check fails, the document building process is terminated.

6. The method according to claim 5, characterized in that, The link validity check is performed by the Sphinx link check builder, and / or The syntax check is performed using a Markdown format validation tool.

7. The method according to claim 1, characterized in that, The method further includes: publishing the document output as an output document.

8. The method according to claim 7, characterized in that, Publishing the document output as an output document includes: rendering the document output as an HTML webpage and deploying it to a static website hosting service.

9. The method according to claim 8, characterized in that, The method further includes: synchronously generating PDF and / or ePub versions of the document output during the document construction process.

10. A computer program product, comprising instructions, characterized in that, When executed by one or more processors, the instructions cause the one or more processors to perform the method according to any one of claims 1-9.

Images