Add documentation(issue #28355)

.github/workflows/maven-release-process.md

@@ -0,0 +1,77 @@
+# Release generation process on GitHub
+
+## How to fire the release generation GitHub action
+
+This document provides a comprehensive guide on how to fire the release generation GitHub action. This action is a crucial step in our release process, enabling us to automate the generation of release artifacts and streamline our deployment workflows.
+
+Here you will find detailed instructions on how to trigger the release generation action, including the necessary setup steps and usual practices. This guide will help you understand the process and successfully execute the action.
+
+## To start
+In the list of GitHub actions provided by DevOps we have one named “Maven Release Process”. This action is the one that we need to fire in order to generate a new Agile release version.
+
+You can see all the available jobs here:  
+- https://github.com/dotCMS/core/actions
+
+In the list you will find the one mentioned above: 
+**![](https://lh7-us.googleusercontent.com/lHWNnEj7aovd8nQhedm3gkir3AIy3J4ERzhbDgYgTeM9MpKri753lp4Emtre1_QUXMHYclc0rJ9zwJ0IGcbt8djWay4hkgL2pHRVzxWy_vXQHGG9KIbkWcIIyH07b4MtS6h7kdykmNTTNb_SMfq0q1Y)**
+
+To run this, we need define some parameter and then fire the job, we can add/remove some specific configuration, let’s talk about those ones
+**![](https://lh7-us.googleusercontent.com/AsWsGI3xNJm6B-GP26HTYE3OxRRMGjLCLhbPdjVpx4X9_mxA7W8D0-GV4paEKrPUUTA4pAVEz9Q_7YohJSnXXMVPxUZkVOO7MR9fAu7FFkVb_1AjUdFi18XpGZ3jaCGpMu68BdRG2FVBc0yKLve_i6g)**
+## Fields & Options
+
+The reason to have options representing different steps as flags is that in the past (and also during workflow development) we had the need to ignore workflow steps since they already work. E.g., if Github as a platform for our pipeline fails and we have already deployed the artifacts, then it does not male sense to repeat this step in the next release attempt.
+
+### Use Workflow from (Required):
+
+This field is used in order to select which branch you want to generate the release for, in the case of agile release we always will generate this from the “trunk (master)” branch.
+
+
+
+### Release Version (Required):
+
+As you know we are using this nomenclature (yy.mm..dd) to generate agile releases, we need to define here the date in order to generate the release with the current date. In this case, the job will add the prefix (Release_) and then will add the provided date.  
+E.G: “Release_24.04.15”.
+
+
+
+### Commit Hash (default latest):
+
+This field is used to define the LAST commit hash that you want to include in the release, it is important to mention by default we will use the last one merged to the branch, but in case you want to generate this with a specific commit, you need to add the complete hash number of the commit.
+
+### Deploy Artifacts (default enabled):
+
+This checkbox is enabled by default and the function is to deploy all the dependencies in artifact with the release version to our artifact repo (repo.dotcms.com). We always need to have this enabled in order to have a success release.
+
+
+
+Update plugins (default enabled):
+
+Same thing here, by default is enabled and the function is to create a plugins version for the release that will be generated by the job. Currently this does not happen in an automated way, therefore this step should be manually run by executing the plugin-seeds repo workflow at [https://github.com/dotCMS/plugin-seeds/actions/workflows/release-target.yml](https://github.com/dotCMS/plugin-seeds/actions/workflows/release-target.yml) matching the same release version value.
+
+
+
+### Update Javadocs:
+
+The javadoc is generated by a specific maven command which will create the entire html bundle for the provided dotCMS version and will finally upload it to our static S3 bucket.
+
+### Update GitHub labels:
+
+This is a work in progress (not done yet) but the idea is to replace the “Next Release” label by a new label created by the job with the name of the release.  
+
+Let’s explain a little bit about the process…  
+
+When the QA team tests any card, they will add the QA Approved // Rejected label, and also the “Next Release” label, that indicates the card is ready to be included into the next release. Once we are going to generate a new agile release, the idea is to filter the cards that are ready to release and generate a new version or release to production.  
+
+Then with this automated job the idea is just take the cards that have the next release label and replace them with the name of the release, in that way we can filter the issues included in the release using the label.
+
+
+
+### Notify in Slack (default enabled):
+
+This field is related to generating a notification in the general slack channel with the announcement of the new release generated. By default this is enabled, but in any case you can disable and skip this in the process.  
+
+
+
+Finally once you set all the parameters, we are ready to release, just click on the “Run Workflow” button and it will start a process in the background in order to deploy everything and finally generate the release version. After some minutes, you will receive a notification on the general slack channel about the new version.  
+
+Also, you can track one by one all the stages and see more details about the process in the page redirected after firing the action.