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.

Plain Client Upgrade

Dear Plain Programmer,

As our team continues to grow, we're making exciting improvements to our code generation service. To support these enhancements, we've introduced a few updates to the client.

All existing Plain source files should remain fully compatible with the new version, but we kindly recommend pulling the latest updates from our repository: https://github.com/Codeplain-ai/plain2code_client.

Best regards,
The Codeplain Team

Better handling of syntax errors in Plain source

In this release we provide better error handling for syntax errors in Plain source. Now it should be much easier to understand what is wrong with the Plain source if the rendering fails.

Besides better handling of syntax errors and fixing a few bugs, this release also:

• updates unittests and conformance tests scripts
• adds Golang console app template to the standard template library
• adds prohibited_chars liquid filter

Standard template library implementation

Introducing support for standard template library. Standard templates are a predefined Plain source files that can be used as a starting point for building applications. Initially standard templates are available for the following languages/application types:

• Python Console Application (python-console-app-template.plain)
• Go Lang Console Application (golang-console-app-template.plain)
• TypeScript React Web Application (typescript-react-app-template.plain)

Standard templates reside in the standard_template_library folder. See also examples for more information how standard templates can be used.

In addition to standard templates and bug fixes, the new version also introduces:

• renaming end-to-end tests to conformance tests to align ourselves with the nomenclature used by Tessl.io,
• '--full-plain' command line flag that returns full plain text source with all templates applied.

Sections support

Added support for sections in Plain source files. This means that Plain source can be organized in sections and subsection using markdown headers. This should enable support for bigger and more complex applications written in Plain in the future.