Destination folder for source and conformance test code

With Plain-Git integration for source and conformance test code set in place, we're introducing the ability to utilize and commit the generated code in the existing repositories.

Destination folder for the generated code

You can copy the source code to source code destination folder

Through the plain2code CLI, you can now set --copy-build (bool) argument, telling if you want to copy the source code into destination folder after a successful rendering. By default, this code is copied into dist/ folder, but you can manage this through --build-dest CLI parameter.

You can copy the conformance tests to source code destination folder

Through the plain2code CLI, you can now set --copy-conformance-tests (bool) argument, telling if you want to copy the conformance test code into conformance test destination folder after a successful rendering. By default, this code is copied into dist_conformance_tests/, but you can manage this through --conformance-tests-dest CLI parameter.

Other Changes

• Raising threshold for max conformance test runs to 20, ensuring smoother code generation
• Minor bugfixes

Standardize commit messages, minor improvements and bug fixes

This release standardizes commit messages in build/ and conformance_tests/ folders. Note that this update doesn't break backwards compatibility, so you can continue rendering from the current state.

Also, minor updates and bug fixes were introduced.

Minor Upgrades and Bugfixes

This update includes minor bugfixes for Git conformance tests and adds retry logic for steps that may fail under unstable network conditions. The run.sh scripts in the examples/ folder were also simplified..

Conformance Tests Git Versioning

After adding source code to git, we're now releasing native git integration for conformance tests as well.

Git Integration for Generated Conformance Tests

Native git integration for version-controlled code generation brings you closer to a natural development experience.

Here's what you can do with this feature:

• Automatic Version Control: Your generated code is now automatically versioned in the conformance_tests/ folder
• Commit History: Each successful conformance tests generation creates a commit.
• Easy History Tracking: Simply navigate to your conformance_tests/ folder and run git log to see the complete evolution of your code

Other notable changes

• Removed flag debug to ensure simpler developer experience
• Increased retry counts for conformance tests and unit tests fixing
• Smart truncation of unit tests error message

Retry requests to server on connection errors

Summary

To ensure more robust rendering, improved handling of connection errors to the server has been implemented.

Support for Unrecoverable Exit Codes

Overview

We're introducing a new feature to help identify environment-related issues early in the development process. This feature allows test scripts to signal unrecoverable environment problems through specific exit codes, helping distinguish between code issues and environment setup problems.

Problem

Developers often encounter situations where tests fail not because of the code itself, but due to missing or misconfigured environment dependencies. Common scenarios include:

• Missing database connections (e.g., Docker container not running)
• Unavailable mock servers
• Missing environment variables
• Network connectivity issues

These "it works on my machine" problems can be frustrating and time-consuming to debug.

Solution

Test scripts can now use specific exit codes to indicate unrecoverable environment issues. When these exit codes are encountered, the system will:

• Immediately halt test execution
• Provide a clear error message indicating an environment problem
• Help developers quickly identify and fix environment setup issues

How to setup unrecoverable exit codes in your unit and conformance test scripts

There are two special exit codes on our end at the moment:

• Exit Code 69 (service unavailable) - Use this when there are system configuration problems
• Exit Code 124 (timeout error) - Use this when there's a timeout in test execution.

Please look at run.sh for an example of raising special exit codes.

Git Versioning, Improved Configuration Management

We're releasing two major updates to enhance the Codeplain development experience:

• Native git integration for version-controlled code generation
• Streamlined configuration management with hierarchical settings

Git Integration for Generated Code

Native git integration for version-controlled code generation brings you closer to a natural development experience.

Here's what you can do with this feature:

• Automatic Version Control: Your generated code is now automatically versioned in the build folder
• Commit History: Each successful code generation creates a new commit
• Easy History Tracking: Simply navigate to your build folder and run git log to see the complete evolution of your code

Configuration Management

Config Files

You can now manage Codeplain CLI parameters through configuration files instead of command-line arguments:

• More flexible parameter management
• Cleaner command-line interface
• Persistent configuration settings

For example, check:

• Configuration template: config.yaml
• Usage example: run.sh

Template Search Path

When looking for templates, Codeplain searches in the following locations in order:

1. The directory containing your plain file
2. Your custom template directory (if specified using --template-dir)
3. Built-in templates in plain2code_client/standard_template_library

This allows you to easily override built-in templates with your custom versions.

Resource File Resolution

When looking for file resources, Codeplain searches in the following locations in order:

1. The directory containing your plain file
2. Your custom template directory (if specified using --template-dir)
3. Built-in templates in plain2code_client/standard_template_library

This allows you to easily override built-in resources with your custom versions.

Improved Developer Experience, Added `--render-from` argument

This release includes a set of small but impactful improvements:

• Added --render-from argument to the Codeplain client to enable rendering from last successful render point.
• Multiple improvements and optimisations to the code rendering engine.

Acceptance Tests

We’re excited to introduce a powerful new feature in the Plain language: Acceptance Tests.

Acceptance tests can be used to further refine the functional requirement and especially to incorporate constraints on the implementation.

Acceptance tests are specified with a keyword ***Acceptance Tests:*** as a subsection within ***Functional Requirements:*** section. Each acceptance test must be an item in a list.

Here's an example of a "Hello, World" application with one acceptance test.

***Functional Requirements:***

- Display "hello, world"

  ***Acceptance Tests:***
    
  - The App shouldn't show logging output in the console output (neither in stdout nor stderr).

Acceptance tests extend conformance tests. The acceptance tests are implemented according to the Test Requirements: specification (see next section).

If you have any questions or feedback, we’d love to hear from you.

Improved Developer Experience

In this release, we've focused on enhancing the developer experience. Console logs have been cleaned up, and the phases of the code generation process are now more clearly defined. Additionally, verbose logs from unit and conformance tests have been redirected to external files, resulting in a much cleaner overall log output. Developers can still access these files to examine detailed test results as needed.

We’ve also strengthened the code generation process by introducing a more robust workflow for handling failed unit tests, particularly after feature requirements have been successfully implemented.