Move to automated version release when intended

[EmbeddedDevops1]

User description

Changes to version.txt trigger the release job. Closes #11.

---

PR Type

enhancement, configuration changes

---

Description

• Replaced the version check job with a change detection job for version.txt to automate the release process.
• Updated the GitHub Actions checkout version to v3 for better performance and features.
• Integrated dorny/paths-filter to detect changes specifically in version.txt.
• Modified the release job to trigger only if there are changes in version.txt, ensuring intentional version increments.

---

Changes walkthrough 📝

	Relevant files
Enhancement	ci_pipeline.yml Automate release process based on changes to version.txt  .github/workflows/ci_pipeline.yml Replaced version check job with a change detection job for version.txt. Updated GitHub Actions checkout version to v3. Added dorny/paths-filter to detect changes in version.txt. Modified release job to depend on the change detection job. +12/-20

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[qodo-merge-pro]

PR Description updated to latest commit (9fbb123)

• Copy walkthrough table to "Files Changed" Tab

[qodo-merge-pro]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	2, because the changes are mostly configuration updates in the CI pipeline, which are straightforward and well-documented. The PR modifies existing jobs and integrates a new action for path filtering, which is a common task and should not require extensive review time.
🧪 Relevant tests	No
⚡ Possible issues	Possible Oversight: The PR removes the explicit version increment check that was previously in place. This could potentially lead to scenarios where the version is not incremented correctly but the release still proceeds if the file version.txt is modified without a proper version update.
🔒 Security concerns	No

[qodo-merge-pro]

PR Code Suggestions ✨

Category	Suggestion	Score
Possible issue	Ensure the workflow fails if the dorny/paths-filter step encounters an error Add a continue-on-error: false property to the dorny/paths-filter step to ensure the workflow fails if this step encounters an error. .github/workflows/ci_pipeline.yml [19-20] - uses: dorny/paths-filter@v2 id: filter + continue-on-error: false Suggestion importance[1-10]: 7 Why: Adding continue-on-error: false ensures that errors in critical steps are not ignored, which is important for workflow reliability. This suggestion correctly targets the newly added step in the PR.	7
Enhancement	Add a name to the dorny/paths-filter step for better readability Add a name property to the dorny/paths-filter step for better readability and easier debugging. .github/workflows/ci_pipeline.yml [19-20] -- uses: dorny/paths-filter@v2 +- name: Filter paths for version changes + uses: dorny/paths-filter@v2 id: filter Suggestion importance[1-10]: 5 Why: Adding a name to the step enhances readability and debugging, which is a good practice. The suggestion correctly targets the newly added step in the PR.	5
	Add a name to the actions/checkout step for better readability Add a name property to the actions/checkout step for better readability and easier debugging. .github/workflows/ci_pipeline.yml [18] -- uses: actions/checkout@v3 +- name: Checkout repository + uses: actions/checkout@v3 Suggestion importance[1-10]: 5 Why: Naming steps improves readability and debugging. The suggestion correctly targets the newly added actions/checkout@v3 step at line 18 in the PR.	5

[EmbeddedDevops1]

I have tested this release process in a new repo:

• Version change in PR: Initial test of release job. EmbeddedDevops1/version_test#1
• No version change in the PR: Updated README. No version change. EmbeddedDevops1/version_test#2

The expected behavior was observed in both PRs.