81b7727817
Move the `appsmithctl` code to RTS. RTS' own build system will build `appsmithctl` as well. We're adding two command scripts, `ctl` and `appsmithctl` to `/opt/bin`, which will be the entrypoints for this. The `appsmithctl` is now just an alias to the much shorter and non-redundancy-inducing `ctl`. We aren't migrating to TypeScript in this PR so we're ignoring the new `ctl` folder in both `tsconfig.json` and `.eslintrc`. That's temporary, the next PR will fix that. ## Automation /test sanity ### 🔍 Cypress test results <!-- This is an auto-generated comment: Cypress test results --> > [!TIP] > 🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉 > Workflow run: <https://github.com/appsmithorg/appsmith/actions/runs/11930931528> > Commit: 90b5f97b801ac8d4b4b0126d85edff3dccc050bd > <a href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=11930931528&attempt=1" target="_blank">Cypress dashboard</a>. > Tags: `@tag.Sanity` > Spec: > <hr>Wed, 20 Nov 2024 10:36:02 UTC <!-- end of auto-generated comment: Cypress test results --> ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [x] No <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced the `appsmithctl` command for easier command execution. - Updated build process to include additional entry points. - **Bug Fixes** - Streamlined Docker build process, enhancing efficiency and reducing complexity. - **Documentation** - Added a new section in the README for `appsmithctl` command description. - **Chores** - Updated dependencies in `package.json`. - Removed obsolete files and workflows to simplify project structure. - **Style** - Added a new ESLint configuration for specific project needs. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
42 lines
2.2 KiB
Markdown
42 lines
2.2 KiB
Markdown
# Appsmith External Integration Test Workflow
|
|
|
|
## Workflow Triggers
|
|
|
|
This workflow is triggered by the "ok to test" command dispatch. It listens for the `repository_dispatch` event with the type `ok-to-test-command`.
|
|
|
|
## Workflow Jobs
|
|
|
|
### `notify`
|
|
|
|
This job is responsible for notifying about the ongoing test run. It creates a comment on the associated pull request with details about the workflow run, commit, and links to various test results.
|
|
|
|
### `server-build`
|
|
|
|
The `server-build` job builds the server-side code. It uses the configuration defined in the `.github/workflows/server-build.yml` file. The job is skipped for running tests.
|
|
|
|
### `client-build`
|
|
|
|
The `client-build` job builds the client-side codebase. It uses the configuration from the `.github/workflows/client-build.yml` file and checks for test files.
|
|
|
|
### `rts-build`
|
|
|
|
The `rts-build` job builds the "rts" (real-time suggestions) package of the client-side codebase. It uses the configuration defined in the `.github/workflows/rts-build.yml` file.
|
|
|
|
### `build-docker-image`
|
|
|
|
The `build-docker-image` job builds and pushes the Docker image for the application. It depends on the successful completion of the `client-build`, `server-build`, and `rts-build` jobs. The Docker image is built with support for both `linux/arm64` and `linux/amd64` platforms.
|
|
|
|
### `ci-test`
|
|
|
|
The `ci-test` job runs continuous integration tests on the Docker image. It depends on the successful completion of the `build-docker-image` job.
|
|
|
|
### `ci-test-result`
|
|
|
|
The `ci-test-result` job collects the results from the `ci-test` and `perf-test` jobs and generates a report. It always runs, and it processes the test results against known failures. The results are then added as a comment on the associated pull request.
|
|
|
|
### `package`
|
|
|
|
The `package` job creates a package for release. It runs only if all previous steps are successful and the reference is either the `release` or `master` branch. The package result is then marked as complete.
|
|
|
|
Please note that this documentation is based on the information provided in the workflow file. For any specific details and further customization, refer to the actual content of the included `.yml` files for each job.
|