Enhanced Development Workflow with Docker Devcontainer and SUSHI 3.5.0 Update

[SvenSommer]

Contributor Pull Request

Enhanced Development Workflow with Docker Devcontainer, Codfsh-Extension and SUSHI 3.5.0 Update

Description

This pull request introduces significant changes to improve the development and validation process of the project. Specifically, I have replaced the old validation.sh script with a more robust Docker container setup. This container is fully integrated with VSCode as a devcontainer, enhancing the development experience and ensuring consistency across environments. A key feature of this devcontainer is the preconfiguration of the codfsh extension, which is a VS Code Extension designed to support the compilation and validation of FHIR profile definitions. With codfsh, users can easily compile and validate FHIR Shorthand (.fsh) files using Sushi and the HAPI validator.

Additionally, I have updated the SUSHI version to 3.5.0, ensuring compatibility with the latest FHIR Shorthand tooling.

Motivation and Context

The motivation behind these changes is to streamline the development and validation process, making it more efficient and consistent. By leveraging a Docker container with the preconfigured codfsh extension, we can ensure that all contributors have immediate access to essential tools for FHIR profile development and validation. This setup reduces setup time and minimizes environment-related issues, leading to a more efficient development process. The update to SUSHI 3.5.0 aligns our project with the latest advancements in FHIR tooling.

Furthermore, I have introduced a new check in the GitHub workflow. This check performs a git diff on the 'Resources/fsh-generated/resources' to ensure that there are no uncommitted changes caused by the pipeline. This is crucial for maintaining the integrity of our source control and ensuring that all changes are properly tracked.

How has this been tested?

The changes have been tested in a local development environment using the updated Docker container. The container was successfully built and integrated with VSCode, and all functionalities were tested to ensure they work as expected. The GitHub workflow was also tested to confirm that the new check correctly identifies uncommitted changes.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this IG / specification.
• My change requires a change to the documentation or narrative (intend) of the IG.
• I have already updated the documentation / narrative (intend) accordingly.