Merge branch '29872-file-field-drag-and-drop-functionality-for-file-u…

…pload' of github.com:dotCMS/core into 29872-file-field-drag-and-drop-functionality-for-file-upload

.github/actions/core-cicd/deployment/deploy-cli-npm/README.md

@@ -12,7 +12,7 @@ Branch to build from.
 
 - **Description**: Branch to build the project from.
 - **Required**: No
-- **Default**: `master`
+- **Default**: `main`
 
 ### `github-token`
 
@@ -58,7 +58,7 @@ Workflow to search for artifacts.
 
 - **Description**: Name of the workflow to search for to get the artifacts.
 - **Required**: No
-- **Default**: `build-test-master.yml`
+- **Default**: `build-test-main.yml`
 
 ### `artifact-id`
 
@@ -74,7 +74,7 @@ Artifact id.
 - name: CLI Publish NPM Package
   uses: ./.github/actions/core-cicd/deployment/deploy-cli-npm
   with:
-    ref: 'master'
+    ref: 'main'
     github-token: ${{ secrets.GITHUB_TOKEN }}
     npm-token: ${{ secrets.NPM_TOKEN }}
     npm-package-name: 'dotcli'

.github/actions/core-cicd/deployment/deploy-cli-npm/action.yml

@@ -4,7 +4,7 @@ inputs:
   ref:
     description: 'Branch to build from'
     required: false
-    default: 'master'
+    default: 'main'
   github-token:
     description: 'GitHub Token'
     required: true

.github/actions/core-cicd/deployment/deploy-javascript-sdk/README.md

@@ -12,7 +12,7 @@ This GitHub Action is designed to automate the process of publishing dotCMS SDK
 
 | Name             | Description                       | Required | Default |
 |------------------|-----------------------------------|----------|---------|
-| `ref`            | Branch to build from              | No       | `master`|
+| `ref`            | Branch to build from              | No       | `main`|
 | `npm-token`      | NPM token                         | Yes      |         |
 | `npm-package-tag`| Package tag                       | No       | `alpha` |
 | `node-version`   | Node.js version                   | No       | `19`    |
@@ -66,7 +66,7 @@ name: 'Publish SDK Libraries'
 on:
   push:
     branches:
-      - master
+      - main
   workflow_dispatch:
 
 jobs:
@@ -76,7 +76,7 @@ jobs:
       - name: Publish to NPM
         uses: ./.github/actions/core-cicd/deployment/deploy-javascript-sdk
         with:
-          ref: 'master'
+          ref: 'main'
           npm-token: ${{ secrets.NPM_TOKEN }}
           npm-package-tag: 'latest'
           node-version: '18'

.github/actions/core-cicd/deployment/deploy-javascript-sdk/action.yml

@@ -16,7 +16,7 @@ inputs:
   ref:
     description: 'Branch to build from'
     required: false
-    default: 'master'
+    default: 'main'
   npm-token:
     description: 'NPM token'
     required: true

.github/actions/core-cicd/maven-job/README.md

@@ -23,7 +23,7 @@ This GitHub Action sets up and runs a Maven job with extensive configuration opt
 | `needs-history` | Runner needs the full git history | Yes | `false` |
 | `requires-node` | Job requires Node.js | Yes | `true` |
 | `cache-sonar` | Cache the SonarQube files | No | `false` |
-| `require-master` | Require the master tag to run this action | Yes | `false` |
+| `require-main` | Require the main tag to run this action | Yes | `false` |
 | `dotcms-license` | The license key for dotCMS | No | `''` |
 | `artifacts-from` | Download artifacts from a previous job | No | `''` |
 | `github-token` | GitHub token for authentication | Yes | - |

.github/actions/core-cicd/maven-job/action.yml

@@ -46,8 +46,8 @@ inputs:
     description: 'Cache the SonarQube files'
     required: false
     default: 'false'
-  require-master:
-    description: 'Require the master tag to run this action'
+  require-main:
+    description: 'Require the main tag to run this action'
     required: true
     default: 'false'
   dotcms-license:
@@ -100,7 +100,7 @@ runs:
       uses: ./.github/actions/core-cicd/prepare-runner
       with:
         cleanup-runner: ${{ inputs.cleanup-runner }}
-        require-master: ${{ inputs.require-master }}
+        require-main: ${{ inputs.require-main }}
         java-version: ${{ inputs.java-version }}
         require-graalvm: ${{ inputs.native || inputs.require-graalvm }}
         graalvm-version: ${{ inputs.graalvm-version }}

.github/actions/core-cicd/prepare-runner/README.md

@@ -1,12 +1,12 @@
 # Prepare Runner Action
 
-This GitHub Action prepares the runner environment with basic setup steps. It provides a flexible way to configure the runner for various workflow requirements, including cleanup, Java setup, and ensuring the master branch is available.
+This GitHub Action prepares the runner environment with basic setup steps. It provides a flexible way to configure the runner for various workflow requirements, including cleanup, Java setup, and ensuring the main branch is available.
 
 ## Features
 
 - Optional runner cleanup for extra disk space
 - Optional Java and GraalVM setup
-- Ensures master branch is available locally if required
+- Ensures main branch is available locally if required
 - Flexible configuration through inputs
 
 ## Inputs
@@ -16,7 +16,7 @@ This GitHub Action prepares the runner environment with basic setup steps. It pr
 | `cleanup-runner` | Perform runner cleanup for extra disk space | Yes | `false` |
 | `require-graalvm` | Install GraalVM | Yes | `false` |
 | `require-java` | Install Java | No | `true` |
-| `require-master` | Ensure master branch is available locally | Yes | `false` |
+| `require-main` | Ensure main branch is available locally | Yes | `false` |
 | `java-version` | Specify the Java version to install | No | - |
 | `graalvm-version` | Specify the GraalVM version to install | No | - |
 
@@ -33,7 +33,7 @@ To use this action in your workflow, add the following step:
     java-version: '17.0.2-tem'
     require-graalvm: 'true'
     graalvm-version: '21.0.2-graalce'
-    require-master: 'true'
+    require-main: 'true'
 ```
 
 
@@ -64,7 +64,7 @@ jobs:
           require-java: 'true'
           java-version: '17.0.2-tem'
           require-graalvm: 'true'
-          require-master: 'true'
+          require-main: 'true'
 
       - name: Build with Maven
         run: mvn clean install
@@ -75,6 +75,6 @@ jobs:
 ## Notes
 
 - The `cleanup-runner` step is useful when you need extra disk space for your workflow.
-- If `require-master` is set to 'true', the action will ensure the master branch is available locally without switching the current branch.
+- If `require-main` is set to 'true', the action will ensure the main branch is available locally without switching the current branch.
 - Java setup is performed by default unless `require-java` is set to 'false'.
 - GraalVM is only installed if `require-graalvm` is set to 'true'.

.github/actions/core-cicd/prepare-runner/action.yml

@@ -1,11 +1,11 @@
 # This composite action prepares the GitHub Actions runner with basic setup steps.
 # It can optionally clean up the runner, set up Java and GraalVM, and ensure the
-# master branch is available locally.
+# main branch is available locally.
 #
 # Features:
 # - Optional runner cleanup for extra disk space
 # - Optional Java and GraalVM setup
-# - Ensures master branch is available locally if required
+# - Ensures main branch is available locally if required
 # - Flexible configuration through inputs
 
 name: 'Prepare Runner'
@@ -22,8 +22,8 @@ inputs:
   require-java:
     description: 'Require java to be installed'
     default: 'true'
-  require-master:
-    description: 'require the master tag to run this action'
+  require-main:
+    description: 'require the main tag to run this action'
     required: true
     default: 'false'
   java-version:
@@ -35,10 +35,10 @@ inputs:
 runs:
   using: 'composite'
   steps:
-    - name: Setup master branch locally without switching current branch
+    - name: Setup main branch locally without switching current branch
       shell: bash
-      if: (github.ref != 'refs/heads/master' && inputs.require-master == 'true')
-      run: git fetch origin master:master
+      if: (github.ref != 'refs/heads/main' && inputs.require-main == 'true')
+      run: git fetch origin main:main
     - name: Cleanup Runner
       if: ${{ inputs.cleanup-runner == 'true' }}
       uses: ./.github/actions/core-cicd/cleanup-runner

.github/actions/legacy-release/rc-changelog/action.yml

@@ -10,7 +10,7 @@ inputs:
   branch:
     description: 'Branch name'
     required: true
-    default: master
+    default: main
   initial_sha:
     description: 'Initial commit sha'
     required: true

.github/data/slack-mappings.json

@@ -167,5 +167,9 @@
   {
     "github_user": "valentinogiardino",
     "slack_id": "U0790HFL64R"
+  },
+  {
+    "github_user": "rsh1k",
+    "slack_id": "U04UP78B6BS"
   }
 ]

.github/filters.yaml

@@ -34,7 +34,7 @@ cli: &cli
   - *full_build_test
   - *backend
 
-sdk_libs: &sdk_libs
+sdk_libs:
   - 'core-web/libs/sdk/**'  
 
 jvm_unit_test:
@@ -44,4 +44,4 @@ jvm_unit_test:
 build:
   - *backend
   - *cli
-  - *frontend
+  - *frontend

.github/workflows/README.md

@@ -120,26 +120,26 @@ A typical PR goes through the following steps:
 5. **Finalize**: Aggregate results from all previous steps.
 6. **Reporting**: Generate a comprehensive report of the PR check process.
 
-## Specific configurations for each top level workflow getting code to trunk (master) branch
+## Specific configurations for each top level workflow getting code to trunk (main) branch
 
 | Workflow            | Trigger                                                                            | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 |---------------------|------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `1-pr.yml`          | Push of a PR to github                                                             | * Should not use secrets as it is run on code that has not been reviewed <br/> * post-workflow-report.yml is run as a separate triggered workflow so it can have access to the secrets it needs <br/> * For speed it does not run tests that should not be impacted by changes in the PR. Filters defined in .github/filters.yaml                                                                                                                                                                                                  |
-| `2.merge-queue.yml` | PR passed its checks and was added to the merge queue                              | * We force run all tests to catch flakey issues or incorrect filters. <br/> * Merge group checks include all the code of PRs ahead of it in the queue.  If successful after merge the master branch will have the same commit id that will end up as the HEAD of master. <br/> failures in the merge queue should be monitored closely for flakey tests or misconfiguration failures here can slow the process for other developers trying to merge                                                                                |
-| `3-trunk.yml`       | Runs on code that was pushed to trunk (master)                                     | * As we already built and tested the same commit in the merge queue we can take advantage of that and use the build artifacts from that workflow to skip these steps <br/> We currently build native cli artifacts in this phase due to the work required we do not want to run on every PR.  <br/> We run snapshot deployments here to github (trunk) deployments, snapshot artifactory etc.                                                                                                                                      |
-| `4-nightly.yml'     | Runs on a nightly schedule and will run on the latest commit on master at the time | * Another chance to capture flakey build issues <br/> We can add longer running tests here that would be impractical to run on every PR merged <br/> Provides a more stable image to compare behavior from previous days <br/> This currently runs using the default 1.0.0-SNAPSHOT image but with release changes this end up with a dated version on a nightly branch.  The workflow triggered from the nightly cron will version and promote the code and a separate nightly workflow will build, test, deploy from that branch |
+| `2.merge-queue.yml` | PR passed its checks and was added to the merge queue                              | * We force run all tests to catch flakey issues or incorrect filters. <br/> * Merge group checks include all the code of PRs ahead of it in the queue.  If successful after merge the main branch will have the same commit id that will end up as the HEAD of main. <br/> failures in the merge queue should be monitored closely for flakey tests or misconfiguration failures here can slow the process for other developers trying to merge                                                                                |
+| `3-trunk.yml`       | Runs on code that was pushed to trunk (main)                                     | * As we already built and tested the same commit in the merge queue we can take advantage of that and use the build artifacts from that workflow to skip these steps <br/> We currently build native cli artifacts in this phase due to the work required we do not want to run on every PR.  <br/> We run snapshot deployments here to github (trunk) deployments, snapshot artifactory etc.                                                                                                                                      |
+| `4-nightly.yml'     | Runs on a nightly schedule and will run on the latest commit on main at the time | * Another chance to capture flakey build issues <br/> We can add longer running tests here that would be impractical to run on every PR merged <br/> Provides a more stable image to compare behavior from previous days <br/> This currently runs using the default 1.0.0-SNAPSHOT image but with release changes this end up with a dated version on a nightly branch.  The workflow triggered from the nightly cron will version and promote the code and a separate nightly workflow will build, test, deploy from that branch |
 
 ## Further verification and promotion phases up to Release
 **In Progress**
 
-The aim is to have the master branch be in a releasable state.  Our preceding steps and validations to get a PR into the master branch should be the primary gates to prevent an unreleasable bad commit.
+The aim is to have the main branch be in a releasable state.  Our preceding steps and validations to get a PR into the main branch should be the primary gates to prevent an unreleasable bad commit.
 
-It is also key to the smooth development process also that issues are not introduced into the master branch that could cause failures when developers merge it into their own branches.
+It is also key to the smooth development process also that issues are not introduced into the main branch that could cause failures when developers merge it into their own branches.
 
-We still need go go through some further validations though before we can approve a specific commit on the master branch as acceptable for release. Some of these tests both automatic and manual can take some time
-so we do not want to block the development process while these are being run.  We will have a separate branch (release) or branches (test?,rc?,release)that will be used to promote the code from the master branch up to a release branch. Each step will provide a higher level of confidence.
+We still need go go through some further validations though before we can approve a specific commit on the main branch as acceptable for release. Some of these tests both automatic and manual can take some time
+so we do not want to block the development process while these are being run.  We will have a separate branch (release) or branches (test?,rc?,release)that will be used to promote the code from the main branch up to a release branch. Each step will provide a higher level of confidence.
 
-We will not make manual changes to these branches, the only changes from the core commit on master that will be made are to set the version for the build.  This should be as minimal as possible and currently for maven can be done by adding just one file .mvn/maven.properties.
+We will not make manual changes to these branches, the only changes from the core commit on main that will be made are to set the version for the build.  This should be as minimal as possible and currently for maven can be done by adding just one file .mvn/maven.properties.
 The more changes to the code are made the more opportunity that there is a change that impacts behavior that was not already tested in the previous steps.
 
 We can make the promotion process a manual action and can also make use of Github deploymnents and environments to specify required reviewers before promotion is done
@@ -157,14 +157,14 @@ Before Nightly run                       After Nightly Promote Step
              
 nightly:    PR1A                             PR1A--PR2B--PR3B--PR4B
              |                                |     |     |     |
-master:   --PR1---PR2---PR3---PR4     run: --PR1---PR2---PR3---PR4
+main:   --PR1---PR2---PR3---PR4     run: --PR1---PR2---PR3---PR4
 ```
-The commits into nightly are not the exact same commit sha as the parent on master
+The commits into nightly are not the exact same commit sha as the parent on main
 The change between the two is determanistic and repreducable.  We only add a ./mvn/maven.config containing the release version to embed and build with by default
-We also provide the original SHA to link back to the source commit on master.  
+We also provide the original SHA to link back to the source commit on main.  
 
-The exact same process can be used with a manual step to select when to sync up master to a test or release candidate branch
-We do not pick and choose individual PRS to sync up,  by default we would pull all the commits up to and including the HEAD commit on master There may 
+The exact same process can be used with a manual step to select when to sync up main to a test or release candidate branch
+We do not pick and choose individual PRS to sync up,  by default we would pull all the commits up to and including the HEAD commit on main There may 
 be a reason to select a previous commit but must always be a commit between what is already merged and the HEAD and will contain all the commits and changes inbetween. 
 The only difference will be the change in release number assigned to the commits which will help us with change logs.
 
@@ -180,12 +180,12 @@ release         PR1a--PR2b--PR3b--PR4b--PR5b--PR6b
                  |x    |     |    |     |     |x
 rc              PR1A--PR2B--PR3B--PR4B--PR5C--PR6C--PR7D
                  |x    |     |     |x    |     |x    |x
-master    run: --PR1---PR2---PR3---PR4---PR5---PR6---PR7---PR8
+main    run: --PR1---PR2---PR3---PR4---PR5---PR6---PR7---PR8
 
 1. PR1 promoted to Release Candidate and RC testing occurs on PR1A  rc-A
 2. PR1A tested and approved for release with new release version.   Release A
-    In the meantime PR2 and PR3 have been added to master and have no impact on RC branch 
-3. PR4 promoted to RC as version B and PR4B tested while PR5 is added to master. RC-B PR2B,PR3B,PR4B included
+    In the meantime PR2 and PR3 have been added to main and have no impact on RC branch 
+3. PR4 promoted to RC as version B and PR4B tested while PR5 is added to main. RC-B PR2B,PR3B,PR4B included
 4. PR4B is not approved for release, PR6 adds a fix is promoted to RC as version C
 5. PR6C is approved for release and promoted to release.
 ```