Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edit Page V2: Automate the deploy of the SDK libraries #28259

Closed
Tracked by #27546
fmontes opened this issue Apr 16, 2024 · 6 comments · Fixed by #29637, #29795, #29832, #29876 or #29976
Closed
Tracked by #27546

Edit Page V2: Automate the deploy of the SDK libraries #28259

fmontes opened this issue Apr 16, 2024 · 6 comments · Fixed by #29637, #29795, #29832, #29876 or #29976

Comments

@fmontes
Copy link
Member

fmontes commented Apr 16, 2024

Parent

#27546

Task description

As a developer working on dotCMS, I want to automate the deployment process of the SDK libraries so that whenever a dotCMS release is generated, the SDK libraries are published to npm with tagged versions and a tag is created for the example/nextjs.

Acceptance Criteria

  • The SDK libraries are automatically published to npm with tagged versions when a dotCMS release is generated.
  • A tag is created for the example/nextjs repository in the dotCMS GitHub organization.
  • The deployment process is triggered automatically and does not require manual intervention.

External Links

Assumptions & Initiation Needs

  • Access to the dotCMS GitHub organization and npm registry is required.
  • The deployment process will be set up using a continuous integration/continuous deployment (CI/CD) tool like Jenkins or GitHub Actions.

Quality Assurance Notes & Workarounds

  • Ensure that the correct version numbers are used when tagging the SDK libraries for npm publication
@fmontes fmontes moved this from New to Gardening Day Backlog in dotCMS - Product Planning May 9, 2024
@nollymar nollymar moved this from Gardening Day Backlog to Next 1-3 Sprints in dotCMS - Product Planning Jul 8, 2024
@dcolina dcolina self-assigned this Jul 8, 2024
@nollymar nollymar moved this from Next 1-3 Sprints to Current Sprint Backlog in dotCMS - Product Planning Jul 11, 2024
dcolina added a commit to dotCMS/core-workflow-test that referenced this issue Jul 17, 2024
dcolina added a commit to dotCMS/core-workflow-test that referenced this issue Jul 17, 2024
…130)

### Proposed Changes
* change 1
* change 2

### Checklist
- [ ] Tests
- [ ] Translations
- [ ] Security Implications Contemplated (add notes if applicable)

### Additional Info
** any additional useful context or info **

### Screenshots
Original             |  Updated
:-------------------------:|:-------------------------:
** original screenshot **  |  ** updated screenshot **
@dcolina dcolina moved this from Current Sprint Backlog to In Progress in dotCMS - Product Planning Jul 29, 2024
dcolina added a commit that referenced this issue Aug 2, 2024
@dcolina dcolina moved this from In Progress to In Review in dotCMS - Product Planning Aug 2, 2024
dcolina added a commit that referenced this issue Aug 7, 2024
@dcolina
Copy link
Contributor

dcolina commented Aug 13, 2024

We are going to change the approach previously implemented. The main idea is to use husky (pre-commit) to detect if the SDKs have been affected in the commit. If that occurs an update version script will run.
In this scenario our workflow would only publish the SDK into the NPM registry, so it would simplify our process and we would avoid automatic PR and possible loop issues.

@fabrizzio-dotCMS fabrizzio-dotCMS removed their assignment Sep 10, 2024
@fabrizzio-dotCMS fabrizzio-dotCMS moved this from Internal QA to Current Sprint Backlog in dotCMS - Product Planning Sep 10, 2024
@dcolina dcolina self-assigned this Sep 12, 2024
github-merge-queue bot pushed a commit that referenced this issue Sep 13, 2024
…28259) (#29976)

### Proposed Changes
This pull request introduces a solution to persist and propagate the
sdk_libs state across multiple phases of the CI/CD workflow in GitHub
Actions, ensuring consistent state management during PR Checks, Merge
Queue Checks, and Master Checks.

Key Steps
1. Use of a Consistent Identifier (BASE_SHA):

A unique identifier (`BASE_SHA`) is determined based on the available
context: `base.sha` for `pull requests`, `merge_group.base_sha` for
`merge queues`, or the `before SHA` for `push` events. This identifier
is consistent across all phases and is used to reference the correct
commit state.

2. Download Existing State Artifact:

In each workflow phase, an attempt is made to download an artifact named
`sdk-status-${BASE_SHA}`. If the artifact exists, its content is used to
define the `sdk_libs` state. If not found, the state is recalculated.

3. Calculate and Upload the Artifact if Necessary:

If no previous artifact is found, the `sdk_libs` state is recalculated
using the `dorny/paths-filter` action. A new artifact named
`sdk-status-${BASE_SHA}` is uploaded with the calculated state if
needed.

### Additional Info
Related to #28259 (Edit Page V2 Automate the deploy of the SDK
libraries).
@github-project-automation github-project-automation bot moved this from In Review to Internal QA in dotCMS - Product Planning Sep 13, 2024
@dcolina dcolina removed their assignment Sep 13, 2024
@dcolina
Copy link
Contributor

dcolina commented Sep 13, 2024

Note to QA: How to Test the Complete Workflow

To verify the changes in this pull request, follow these steps to test the full CI/CD workflow in GitHub Actions, ensuring correct state persistence and propagation across PR Checks, Merge Queue Checks, and Master Checks.

1. Test PR Checks Workflow

  • Open a Pull Request:

    1. Create a new branch and make changes that affect the SDK (e.g., modify SDK-related files).
    2. Open a pull request (PR) to the master branch.
  • Verify Artifact Creation:

    1. Ensure the PR Checks workflow runs.
    2. Confirm the sdk-status artifact is uploaded with the correct name (sdk-status-${BASE_SHA}).
    3. Check that the sdk_libs value is correctly determined and stored.

2. Test Merge Queue Workflow

  • Approve and Queue the PR:

    1. Approve the PR and add it to the merge queue.
  • Verify Artifact Retrieval:

    1. Confirm the Merge Queue Checks workflow is triggered.
    2. Ensure it attempts to download the sdk-status-${BASE_SHA} artifact and retrieves the correct sdk_libs state.

3. Test Master Checks Workflow

  • Merge the PR:

    1. Complete the PR merge to the master branch.
  • Verify State and Deployment:

    1. Ensure the Master Checks workflow runs.
    2. Check the logs for the download of the sdk-status-${BASE_SHA} artifact.
    3. Verify that the sdk_libs state is correctly retrieved, and if true, confirm the SDK is deployed to the NPM registry.

4. Edge Case Testing

  • No SDK Changes:

    1. Open a PR without SDK changes.
    2. Verify no sdk-status artifact is uploaded and sdk_libs remains false.
  • Multiple PRs:

    1. Open multiple PRs that modify SDK files.
    2. Ensure each PR has a unique sdk-status artifact and the correct state is propagated.

5. Check SDK Deployment to NPM Registry

  • Confirm SDK Deployment:
    1. After merging, verify the SDK is correctly published to the NPM registry with the expected updates.

Expected Results

  • sdk_libs state is consistently maintained across all workflow phases.
  • Correct artifact management and state propagation.
  • Accurate deployment to the NPM registry when necessary.

By following these steps, you will ensure that the workflow changes work as intended across all phases.

@nollymar nollymar reopened this Sep 13, 2024
@github-project-automation github-project-automation bot moved this from Internal QA to Current Sprint Backlog in dotCMS - Product Planning Sep 13, 2024
@nollymar nollymar moved this from Current Sprint Backlog to Internal QA in dotCMS - Product Planning Sep 13, 2024
dsolistorres pushed a commit that referenced this issue Sep 18, 2024
…28259) (#29832)

### Proposed Changes
* This pull request updates the function sends Slack notifications using
slackapi/[email protected], handling both plain text messages
and preformatted JSON payloads. It dynamically selects the appropriate
format based on a boolean input (json), ensuring correct handling of
Slack message formatting and maintaining compatibility with different
notification types.

### Additional Info
Related to #28259 (Edit Page V2 Automate the deploy of the SDK librar).
dsolistorres pushed a commit that referenced this issue Sep 18, 2024
…28259) (#29876)

### Proposed Changes
* This pull request introduces an improved approach for managing version
increments and dependency updates for the dotCMS SDK libraries. Unlike
the previous solution that handled version calculations locally before
committing, this new method performs version calculation and updates
directly within the continuous integration flow, specifically after a
merge and during the deployment phase.

The new solution ensures that all SDK libraries in the repository are
updated centrally and consistently. Key improvements include:

Version Updates: Automatically increments the version of each SDK
package found in the relevant directory.
Dependency Management: Updates peerDependencies between SDK libraries to
maintain internal compatibility.
NPM Publishing: Publishes each updated SDK library to the NPM registry,
ensuring that the latest versions are readily available.

### Additional Info
Related to #28259 (Edit Page V2 Automate the deploy of the SDK librar).
@nollymar
Copy link
Contributor

This card can be tested only when an SDK needs to be generated. As we don't need to do it now, in case an issue comes up at that moment, a new card will be filed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment