Merge branch 'master' into renovate/docker.io-library-gradle-8.10.0-j…

…dk21

.github/ISSUE_TEMPLATE/1-bug-report.md

@@ -0,0 +1,33 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ""
+labels: ""
+assignees: ""
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+
+1. Go to '...'
+1. Click on '....'
+1. Scroll down to '....'
+1. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Server (please complete the following information):**
+
+- OS: [e.g. Ubuntu 24.04]
+- Container Runtime [e.g. docker, containerd, cri-o, podman]
+- Container Runtime Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/2-feature-request.md

@@ -0,0 +1,19 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ""
+labels: ""
+assignees: ""
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/ISSUE_TEMPLATE/3-custom.md

@@ -0,0 +1,7 @@
+---
+name: Custom issue template
+about: For anything that isn't a bug or feature request.
+title: ""
+labels: ""
+assignees: ""
+---

.github/PULL_REQUEST_TEMPLATE/pull-request-template.md

@@ -0,0 +1,15 @@
+## Describe your changes
+
+<!-- It's OK to be brief. Or skip this entirely if the changes are obvious. -->
+
+## Issue ticket number and link
+
+<!-- Optional -->
+
+## Checklist before requesting a review
+
+<!-- It's OK not to update the documentation or create new tests if deemed unnecessary -->
+
+- [ ] The commit message follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) standard
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] I have made corresponding changes to the documentation

.github/workflows/ci.yml

@@ -16,7 +16,7 @@ permissions: read-all
 
 jobs:
   build:
-    uses: miracum/.github/.github/workflows/standard-build.yaml@49140a0c55dda78f1694ffb02ef3b182a3347756 # v1.12.2
+    uses: miracum/.github/.github/workflows/standard-build.yaml@b2389048770aa5b9ed439810bf84911fbb07f645 # v1.12.3
     permissions:
       contents: write
       id-token: write
@@ -70,7 +70,7 @@ jobs:
 
       - name: Add coverage to PR
         id: jacoco
-        uses: madrapps/jacoco-report@db72e7e7c96f98d239967958b0a0a6ca7d3bb45f # v1.6.1
+        uses: madrapps/jacoco-report@642c39173b270639beeba5e2c6c160bfbba33388 # v1.7.0
         with:
           paths: |
             ${{ github.workspace }}/test/jacoco/test/jacocoTestReport.xml
@@ -148,14 +148,14 @@ jobs:
 
       - name: Upload cluster dump
         if: always()
-        uses: actions/upload-artifact@834a144ee995460fba8ed112a2fc961b36a5ec5a # v4.3.6
+        uses: actions/upload-artifact@50769540e7f4bd5e21e526ee35c689e35e0d6874 # v4.4.0
         with:
           name: kind-cluster-dump.txt
           path: |
             kind-cluster-dump.txt
 
   lint:
-    uses: miracum/.github/.github/workflows/standard-lint.yaml@49140a0c55dda78f1694ffb02ef3b182a3347756 # v1.12.2
+    uses: miracum/.github/.github/workflows/standard-lint.yaml@b2389048770aa5b9ed439810bf84911fbb07f645 # v1.12.3
     permissions:
       contents: read
       pull-requests: write
@@ -170,7 +170,7 @@ jobs:
       github-token: ${{ secrets.GITHUB_TOKEN }}
 
   release:
-    uses: miracum/.github/.github/workflows/standard-release.yaml@49140a0c55dda78f1694ffb02ef3b182a3347756 # v1.12.2
+    uses: miracum/.github/.github/workflows/standard-release.yaml@b2389048770aa5b9ed439810bf84911fbb07f645 # v1.12.3
     needs:
       - lint
       - build

.github/workflows/schedule.yaml

@@ -10,7 +10,7 @@ permissions: read-all
 
 jobs:
   schedule:
-    uses: miracum/.github/.github/workflows/standard-schedule.yaml@49140a0c55dda78f1694ffb02ef3b182a3347756 # v1.12.2
+    uses: miracum/.github/.github/workflows/standard-schedule.yaml@b2389048770aa5b9ed439810bf84911fbb07f645 # v1.12.3
     permissions:
       contents: read
       issues: write

.github/workflows/scorecard.yaml

@@ -59,14 +59,14 @@ jobs:
       # Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF
       # format to the repository Actions tab.
       - name: "Upload artifact"
-        uses: actions/upload-artifact@834a144ee995460fba8ed112a2fc961b36a5ec5a # v4.3.6
+        uses: actions/upload-artifact@50769540e7f4bd5e21e526ee35c689e35e0d6874 # v4.4.0
         with:
           name: SARIF file
           path: results.sarif
           retention-days: 5
 
       # Upload the results to GitHub's code scanning dashboard.
       - name: "Upload to code-scanning"
-        uses: github/codeql-action/upload-sarif@4dd16135b69a43b6c8efb853346f8437d92d3c93 # v3.26.6
+        uses: github/codeql-action/upload-sarif@8214744c546c1e5c8f03dde8fab3a7353211988d # v3.26.7
         with:
           sarif_file: results.sarif

.github/workflows/validate-fhir-resources.yaml

@@ -12,7 +12,7 @@ jobs:
   validate-fhir-resource:
     name: Validate FHIR resources
     runs-on: ubuntu-22.04
-    container: ghcr.io/miracum/ig-build-tools:v2.1.5@sha256:4571ddd801664e2ee8883ae9c22f88d2c5dfe1175b1e93f042ae8bfa9a7e185a
+    container: ghcr.io/miracum/ig-build-tools:v2.1.6@sha256:26bc1eaf0a259e8c16d0eeeb8622c7aecaa45d41e39f158696f9aec90b142596
     steps:
       - name: Checkout code
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7

.markdownlint.json

@@ -0,0 +1,17 @@
+{
+  "MD004": false,
+  "MD007": {
+    "indent": 2
+  },
+  "MD013": {
+    "line_length": 400
+  },
+  "MD026": {
+    "punctuation": ".,;:!。，；:"
+  },
+  "MD029": false,
+  "MD033": false,
+  "MD036": false,
+  "blank_lines": false,
+  "MD041": false
+}

CONTRIBUTING.md

@@ -0,0 +1,44 @@
+# Contributing
+
+## License
+
+By contributing, you agree that your contributions will be licensed under the [GNU General Public License Version 3.0 (GPL-3.0 license)](LICENSE).
+
+## Contribution process
+
+This is the process we suggest for contributions. This process is designed to reduce the burden on project reviewers,
+impact on other contributors, and to keep the amount of rework from the contributor to a minimum.
+
+1. Start a discussion by creating a GitHub issue, or asking on Slack (unless the change is trivial, for example a spelling fix in the documentation).
+
+   1. This step helps you identify possible collaborators and reviewers.
+   1. Does the change align with technical vision and project values?
+   1. Will the change conflict with another change in progress? If so, work with others to minimize impact.
+   1. Is this change large? If so, work with others to break into smaller steps.
+
+1. Implement the change
+
+   1. Create or update your own fork of the repository.
+   1. If the change is large, post a draft GitHub pull request.
+   1. Include tests and documentation as necessary.
+   1. Follow the commit message guidelines and other suggestions from the [development guidelines](DEVELOPMENT.md).
+
+1. Create a GitHub pull request (PR).
+
+   1. If you already have a draft PR, change it to ready for review.
+   1. Refer to the GitHub documentation for more details about collaborating with PRs.
+   1. Make sure the pull request passes the tests in CI.
+   1. Code reviewers are automatically assigned.
+
+1. Review is performed by one or more reviewers.
+
+   1. This normally happens within a few days, but may take longer if the change is large, complex, or if a critical reviewer is unavailable. (feel free to ping the reviewer or team on the pull request).
+
+1. Address concerns and update the pull request.
+
+   1. Comments are addressed to each individual commit in the pull request, and changes should be addressed in a new fixup! commit placed after each commit. This is to make it easier for the reviewer to see what was updated.
+   1. After pushing the changes, add a comment to the pull-request, mentioning the reviewers by name, stating that the review comments have been addressed. This is the only way that a reviewer is notified that you are ready for the code to be reviewed again.
+
+1. Maintainer merges the pull request after final changes are accepted.
+
+1. Merging your improvements will usually trigger a new release once merged

DEVELOPMENT.md

@@ -0,0 +1,123 @@
+# Development
+
+Inspired by <https://github.com/trinodb/trino/blob/master/.github/DEVELOPMENT.md>.
+
+## Commits and pull requests
+
+### Format Git commit messages
+
+We format commit messages to adhere to the [conventional commit standard](https://www.conventionalcommits.org/en/v1.0.0/).
+The commit messages are also used to automatically create and version releases using [semantic-release](https://semantic-release.gitbook.io/semantic-release).
+
+### Git merge strategy
+
+Pull requests are usually merged into `master` using the [`rebase and merge`](https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#rebase-and-merge-your-pull-request-commits) strategy.
+
+A typical pull request should strive to contain a single logical change (but not
+necessarily a single commit). Unrelated changes should generally be extracted
+into their own PRs.
+
+If a pull request contains a stack of more than one commit, then
+popping any number of commits from the top of the stack, should not
+break the PR, ie. every commit should build and pass all tests.
+
+Commit messages and history are important as well, because they are
+used by other developers to keep track of the motivation behind
+changes. Keep logical diffs grouped together in separate commits and
+order commits in a way that explains by itself the evolution of the
+change. Rewriting and reordering commits is a natural part of the
+review process. Mechanical changes like refactoring, renaming, removing
+duplication, extracting helper methods, static imports should be kept
+separated from logical and functional changes like adding a new feature
+or modifying code behaviour. This makes reviewing the code much easier
+and reduces the chance of introducing unintended changes in behavior.
+
+Whenever in doubt on splitting a change into a separate commit, ask
+yourself the following question: if all other work in the PR needs to
+be reverted after merging to master for some objective reason (eg. a
+bug has been discovered), is it worth keeping that commit still in
+master.
+
+## Code Style
+
+We recommend you use IntelliJ as your IDE. The code style used is the [Google Java style](https://google.github.io/styleguide/javaguide.html).
+It is automatically enforced using [spotless](https://github.com/diffplug/spotless).
+
+To run spotless and other checks before opening a PR: `./gradlew :check`
+
+In addition to those you should also adhere to the following:
+
+### Readability
+
+The purpose of code style rules is to maintain code readability and developer
+efficiency when working with the code. All the code style rules explained below
+are good guidelines to follow but there may be exceptional situations where we
+purposefully depart from them. When readability and code style rule are at odds,
+the readability is more important.
+
+### Consistency
+
+Keep code consistent with surrounding code where possible.
+
+### Alphabetize
+
+Alphabetize sections in the documentation source files (both in the table of
+contents files and other regular documentation files).
+
+### Use streams
+
+When appropriate, use the stream API. However, note that the stream
+implementation does not perform well so avoid using it in inner loops or
+otherwise performance sensitive sections.
+
+### Prefer String formatting
+
+Consider using String formatting (printf style formatting using the Java
+`Formatter` class): `format("Session property %s is invalid: %s", name, value)`
+(note that `format()` should always be statically imported). Sometimes, if you
+only need to append something, consider using the `+` operator. Please avoid
+`format()` or concatenation in performance critical sections of code.
+
+### Avoid ternary operator
+
+Avoid using the ternary operator except for trivial expressions.
+
+### Define class API for private inner classes too
+
+It is suggested to declare members in private inner classes as public if they
+are part of the class API.
+
+### Use AssertJ
+
+Prefer AssertJ for complex assertions.
+
+### Maintain production quality for test code
+
+Maintain the same quality for production and test code.
+
+### Avoid abbreviations
+
+Please avoid abbreviations, slang or inside jokes as this makes harder for
+non-native english speaker to understand the code. Very well known
+abbreviations like `max` or `min` and ones already very commonly used across
+the code base like `ttl` are allowed and encouraged.
+
+### Avoid default clause in exhaustive enum-based switch statements
+
+Avoid using the `default` clause when the switch statement is meant to cover all
+the enum values. Handling the unknown option case after the switch statement
+allows static code analysis tools (e.g. Error Prone's `MissingCasesInEnumSwitch`
+check) report a problem when the enum definition is updated but the code using
+it is not.
+
+### Use constructor injection
+
+Prefer [constructor-based dependency injection](https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-collaborators.html#beans-constructor-injection)
+over field or setter injection.
+
+## Releases
+
+The project aims for frequent releases. We achieve this using semantic-release, where
+each merged PR can create a new release. This allows users of the application to quickly
+receive bug fixes without waiting for arbitrary release cycles. This only works if the
+quality of the code and especially the tests is up-to-par.

Dockerfile

@@ -23,7 +23,7 @@ apt-get clean
 rm -rf /var/lib/apt/lists/*
 EOF
 
-FROM gcr.io/distroless/java21-debian12:nonroot@sha256:5723ccd77a896c16242057b788a3341b265329fc1cbcb5b0add34cfd97057554
+FROM gcr.io/distroless/java21-debian12:nonroot@sha256:b76becbcc22abb3aa840d01db307f8dac837beea47f838bd4f62d60788164214
 WORKDIR /opt/obds-to-fhir
 ENV LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libjemalloc.so"
 

build.gradle

@@ -8,7 +8,7 @@ plugins {
 }
 
 group = 'org.miracum.streams.ume'
-version = '2.1.3'
+version = '2.2.0'
 sourceCompatibility = '21'
 targetCompatibility = '21'