fix(deployment): SDK publishing failure due to missing or incorrect (#30246)

[dcolina]

Proposed Changes

• This PR fixes an authentication issue in the SDK publishing process by ensuring the correct token is provided. The previous configuration caused authentication failures (npm ERR! need auth) due to a missing or incorrect token.

Additional Info

This PR resolves #30246 (SDK publishing failure due to missing or incorrect).

This PR fixes: #30246

[spbolton]

I am assuming here we need to have the node version here be independent from the node version we build with. If not we should be relying on the node and npm managed from maven with core-web. The prepare maven action has a "requires-node" option that sets up maven. I am just not sure if we need to do something different here due to it being the sdk.

[dcolina]

I am assuming here we need to have the node version here be independent from the node version we build with. If not we should be relying on the node and npm managed from maven with core-web. The prepare maven action has a "requires-node" option that sets up maven. I am just not sure if we need to do something different here due to it being the sdk.

Done. @spbolton Now node and npm are managed through the prepare maven action.

[spbolton]

If we only need to install the right version of node and not generating other maven artifacts.
then the maven args could be
‘process-resources -pl :dotcms-core-web -am’
The (-am) also make is to ensure it picks up the parent poms.
The frontend-maven plugin runs in the generate-resources phase and the maven-antrun-plugin creates/updates the .nvmrc file in process-resources phase, and you do not need to go any further e.g. the next phase is compile so it will stop before compiling anything. you could still add clean, but there is no need really as there is nothing to clean really.
The phases are here for reference https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#default-lifecycle
Now in theory the node and yarn binaries should be still in the cache from previous build, the maven-job action restores this cache, but there is no harm in re-running here.
What I think we are not doing is setting the $PATH in the runner for yarn and node to the versions we restore into the installs folder in the repo root.
just running yarn etc. will likely not use the version maven downloaded or restored from the cache.

We have code in our pre-commit hook that sets up node and yarn from these versions and we can do similar or wrap in an action. Just realized that the mvnw validate in our pre-commit hook is not enough to ensure the yarn and node are downloaded. Most of the time this is not a problem because a previous build will have created these files, but we will need to fix this.

if ! ./mvnw validate -pl :dotcms-core --am -q; then
    print_color "$RED" "Failed to run './mvnw validate -pl :dotcms-core --am'"
    print_color "$YELLOW" "Please run the following command to see the detailed output:"
    printf "./mvnw validate -pl :dotcms-core --am\n"
    exit 1
else
    printf "Completed Maven init\n"
fi

# Update PATH to include project-specific Node.js and Yarn
export PATH="${root_dir}/installs/node:${root_dir}/installs/node/yarn/dist/bin:$PATH"

# Verify that node and yarn are accessible
if ! command -v node > /dev/null 2>&1 || ! command -v yarn > /dev/null 2>&1; then
    print_color "$RED" "Error: Node.js or Yarn not found in the project directory."
    print_color "$YELLOW" "Please ensure they are installed in ${root_dir}/installs/node"
    exit 1
fi

[dcolina]

If we only need to install the right version of node and not generating other maven artifacts. then the maven args could be ‘process-resources -pl :dotcms-core-web -am’ The (-am) also make is to ensure it picks up the parent poms. The frontend-maven plugin runs in the generate-resources phase and the maven-antrun-plugin creates/updates the .nvmrc file in process-resources phase, and you do not need to go any further e.g. the next phase is compile so it will stop before compiling anything. you could still add clean, but there is no need really as there is nothing to clean really. The phases are here for reference https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#default-lifecycle Now in theory the node and yarn binaries should be still in the cache from previous build, the maven-job action restores this cache, but there is no harm in re-running here. What I think we are not doing is setting the $PATH in the runner for yarn and node to the versions we restore into the installs folder in the repo root. just running yarn etc. will likely not use the version maven downloaded or restored from the cache.

Done. @spbolton This has been updated setting up the correct path to the restored node and yarn versions.

We have code in our pre-commit hook that sets up node and yarn from these versions and we can do similar or wrap in an action. Just realized that the mvnw validate in our pre-commit hook is not enough to ensure the yarn and node are downloaded. Most of the time this is not a problem because a previous build will have created these files, but we will need to fix this.

if ! ./mvnw validate -pl :dotcms-core --am -q; then
    print_color "$RED" "Failed to run './mvnw validate -pl :dotcms-core --am'"
    print_color "$YELLOW" "Please run the following command to see the detailed output:"
    printf "./mvnw validate -pl :dotcms-core --am\n"
    exit 1
else
    printf "Completed Maven init\n"
fi

# Update PATH to include project-specific Node.js and Yarn
export PATH="${root_dir}/installs/node:${root_dir}/installs/node/yarn/dist/bin:$PATH"

# Verify that node and yarn are accessible
if ! command -v node > /dev/null 2>&1 || ! command -v yarn > /dev/null 2>&1; then
    print_color "$RED" "Error: Node.js or Yarn not found in the project directory."
    print_color "$YELLOW" "Please ensure they are installed in ${root_dir}/installs/node"
    exit 1
fi

This part it will faced in another card.

[dotcms-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube