Following the latest retro, we suggested to generate GH releases when pushing to trunk with a unique ID to keep track.
This adds a GH action to create a release everytime a commit is done to trunk. This should be at QA's responsibility so that they keep track of main "versions".
Documentation
User documentation
Following the latest retro, we suggested to generate GH releases when pushing to trunk with a unique ID to keep track.
This adds a GH action to create a release everytime a commit is done to trunk. This should be at QA's responsibility so that they keep track of main "versions".
Technical documentation
The GIT_TOKEN is added as a repo secret from my account.
Type of change
Delete options that are not relevant.
[x] New feature (non-breaking change which adds functionality).
[ ] Bug fix (non-breaking change which fixes an issue).
[ ] Enhancement (non-breaking change which improves an existing functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as before).
New dependencies
GH actions to generate the release: low risk.
Risks
NA
Checklists
Feature validation
[ ] I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
[ ] I triggered all changed lines of code at least once without new errors/warnings/notices.
[ ] I implemented built-in tests to cover the new/changed code.
Documentation
[x] I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
[x] The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
[x] I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.
Code style
[x] I wrote self-explanatory code about what it does.
[x] I wrote comments to explain why it does it.
[x] I named variables and functions explicitely.
[x] I protected entry points against unexpected inputs.
[x] I did not introduce unecessary complexity.
[x] I listed the introduced external dependencies explicitely on the PR.
[x] I validated the repo-specific guidelines from CONTRIBUTING.md.
Observability
[x] I handled errors when needed.
[x] I wrote user-facing messages that are understandable and provide actionable feedbacks.
[x] I prepared ways to observe the implemented system (logs, data, etc.).
Risks
[x] I explicitely mentioned performance risks in the PR.
[x] I explicitely mentioned security risks in the PR.
Description
Following the latest retro, we suggested to generate GH releases when pushing to trunk with a unique ID to keep track. This adds a GH action to create a release everytime a commit is done to trunk. This should be at QA's responsibility so that they keep track of main "versions".
Documentation
User documentation
Following the latest retro, we suggested to generate GH releases when pushing to trunk with a unique ID to keep track. This adds a GH action to create a release everytime a commit is done to trunk. This should be at QA's responsibility so that they keep track of main "versions".
Technical documentation
The GIT_TOKEN is added as a repo secret from my account.
Type of change
Delete options that are not relevant.
New dependencies
GH actions to generate the release: low risk.
Risks
NA
Checklists
Feature validation
Documentation
Code style
Observability
Risks