No changes in functionality

What's Changed

• Bump fastapi from 0.103.2 to 0.109.1 by @dependabot in #455
• Bump aiohttp from 3.8.6 to 3.9.4 by @dependabot in #463
• Bump setuptools from 68.2.2 to 70.0.0 by @dependabot in #462
• Bump certifi from 2023.7.22 to 2024.7.4 by @dependabot in #466
• Bump requests from 2.31.0 to 2.32.2 by @dependabot in #461
• Bump jinja2 from 3.1.2 to 3.1.4 by @dependabot in #465
• Bump idna from 3.4 to 3.7 by @dependabot in #467
• Bump tornado from 6.3.3 to 6.4.1 by @dependabot in #464
• Bump urllib3 from 2.0.7 to 2.2.2 by @dependabot in #460
• Bump fastapi from 0.109.1 to 0.112.0 by @dependabot in #470
• Bump pydantic from 2.4.2 to 2.8.2 by @dependabot in #471
• Bump docker/build-push-action from 3 to 6 by @dependabot in #478
• Bump actions/setup-node from 3 to 4 by @dependabot in #423
• bumping dependencies and python version by @defreng in #484

Full Changelog: v2.3.3...v2.3.4

This release fixes an edge case, where it was impossible to recover from an incarnation update when the MR was created, but not recorded in the database.

If this happens, an error message will be shown in the foxops log that now looks like this:

foxops.services.change.IncompleteChange: the given change is in an incomplete state (MR ID/Branch = null). Try 'POST /api/incarnations/1/changes/2/fix'

The mentioned endpoint has to be manually called to repair the broken incarnation state in the foxops database

This release fixes a problem where incarnations were not stored correctly, if the user-provided variable values are (partially) equal to the default values of certain variables.

this patch release is fixing a small issue when using foxops "in dev mode" with an SQLite database. In this setup, foreign keys weren't enforced which lead to undesired behavior when removing incarnations (changes in the change table were becoming orphaned).

New Features

• The UI now supports providing and editing nested template variables and lists
• There is a new PATCH /incarnation/{id} endpoint which has the same behavior as the previous PUT endpoint (see breaking changes below)

Breaking Changes & Deprecations

• Behavior of the PUT /incarnation/{id} endpoint changed to no longer behave as a PATCH endpoint. When using the PUT endpoint, from now on the complete set of template variable values has to be provided (it no longer remembers the previous used values).
  • in case the old behavior is needed, there is a new PATCH endpoint available.

Bug Fixes

• the changes API was returning wrong status information for changes with merge requests. this has been fixed.

New Features

• support for template variables of a more complex shape and form (docs):
  • new boolean variable type
  • new list variable type (for now, only supporting lists of strings)
  • new object variable type which allows variables to be nested in more complex structures and introduce some grouping
• improved handling variables that have defaults (see #108)
  • previously, when incarnations were created from a template without specifying values for variables that have defaults, these defaults were saved in the incarnation state as if the user had specified them explicitly. This caused that a change of default values in the template, to not be reflected in the incarnation after an update. Even if the user did not specify the default value explicitly.
  • now foxops separates the user-specified values from what is defined in the template

Breaking Changes & Deprecations

• the allow_import parameter on the create incarnation endpoint was completely removed
• the support for template variables of type float was removed
• support for reading variables from a defaults.fvars file in the incarnation repository was removed

Bug Fixes

• the changes API was returning wrong status information for changes with merge requests. this has been fixed.

even more stable builds

just a bugfix release that fixes the build of 2.1.0