## Description
The current state is default schema or public schema. This schema is
accessible by default when user connects to the pg database. Hence
create `appsmith` schema for Appsmith server to use. This is to avoid
anyone accidentally modifying the appsmith data.
## Automation
/ok-to-test tags="@tag.Sanity"
### 🔍 Cypress test results
<!-- This is an auto-generated comment: Cypress test results -->
> [!IMPORTANT]
> 🟣🟣🟣 Your tests are running.
> Tests running at:
<https://github.com/appsmithorg/appsmith/actions/runs/11111681323>
> Commit: 32f91e8d7ce750e4a088996aff4abe6905aa982f
> Workflow: `PR Automation test suite`
> Tags: `@tag.Sanity`
> Spec: ``
> <hr>Mon, 30 Sep 2024 18:08:23 UTC
<!-- end of auto-generated comment: Cypress test results -->
## Communication
Should the DevRel and Marketing teams inform users about this change?
- [ ] Yes
- [ ] No
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Introduced a script to initialize the PostgreSQL database schema for
Appsmith.
- Added utilities for managing PostgreSQL database connections,
including availability checks and parameter extraction.
- Enhanced scripts for managing PostgreSQL connections and
initialization.
- Improved environment configuration for PostgreSQL database
connections, including automatic password generation for local setups.
- Updated JDBC URL handling to include schema parameters for PostgreSQL
connections.
- Added support for proxy configuration in the application setup.
- **Bug Fixes**
- Improved error handling and connection retry mechanisms for PostgreSQL
setup.
- **Documentation**
- Updated comments and logging for better clarity on database
operations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Abhijeet <abhi.nagarnaik@gmail.com>
## Description
As in the past we have seen the corruption of postgres DB which is being
used for temporal we want to make sure we have a retry mechanism in
place if:
1. `APPSMITH_DB_URL` is pointing to postgres url
2. Postgres is waiting in recovery mode
As per local testing when the docker container is abruptly shutdown via
`docker rm -f {container_name}` or `docker kill {container_name}` or
even via docker desktop we end up in state where postgres goes into
recovery state.
logs:
```
2024-09-27 08:02:49 backend stdout | SQL State : 57P03
2024-09-27 08:02:49 backend stdout | Error Code : 0
2024-09-27 08:02:49 backend stdout | Message : FATAL: the database system is starting up
```
Currently we have implemented polling mechanism, but we will keep
looking for better alternative here if we can opt for.
Note:
1. With release dump this is taking ~300sec to get out of that state and
start accepting the connections.
2. With the existing implementation without retries server dies down
within 60sec.
```
INFO exited: backend (exit status 1; not expected)
INFO gave up: backend entered FATAL state, too many start retries too quickly
```
Reference doc:
https://www.notion.so/appsmith/Postgres-critical-scenarios-668f49c96aef40308e24c2a8d6b1137c
/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/11100944184>
> Commit: 9dbbe4b22ba12aa82c385ad0eef3cc3d4876f217
> <a
href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=11100944184&attempt=1"
target="_blank">Cypress dashboard</a>.
> Tags: `@tag.Sanity`
> Spec:
> <hr>Mon, 30 Sep 2024 07:26:41 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
## Summary by CodeRabbit
- **New Features**
- Introduced new functions for enhanced handling of PostgreSQL database
connections, including availability checks and parameter extraction.
- Added a new utility script for managing PostgreSQL connections.
- **Bug Fixes**
- Implemented a retry mechanism for PostgreSQL server availability
checks to ensure more reliable connections.
- **Tests**
- Added unit tests to validate the functionality of the PostgreSQL
parameter extraction logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
PR to make the release tag adaptable to work with both MongoDB and
PostgreSQL uris.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new script to automate the preparation of server
artifacts, improving the build process.
- Added SQL files to the indentation configuration for consistent code
formatting.
- **Improvements**
- Enhanced error handling in the Docker build process to ensure
essential files are present before execution.
- Updated service configuration logic to prevent misconfiguration based
on the environment.
- Added a new job step in the build workflow to prepare server artifacts
after the build process.
- Implemented conditional logic in the run script to dynamically adapt
to different database configurations.
- **Bug Fixes**
- Adjusted the initialization process to focus on MongoDB, improving
reliability in various environments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
/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/10940528231>
> Commit: 32731e8a93a25e5c9456eb89daca2d8bf327c012
> <a
href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=10940528231&attempt=1"
target="_blank">Cypress dashboard</a>.
> Tags: `@tag.Sanity`
> Spec:
> <hr>Thu, 19 Sep 2024 12:21:54 UTC
<!-- end of auto-generated comment: Cypress test results -->
## Communication
Should the DevRel and Marketing teams inform users about this change?
- [ ] Yes
- [x] No
**/test sanity**
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Refactor**
- Updated logging mechanism from `echo` to `tlog` for improved log
management across various scripts.
- **Chores**
- Enhanced logging for better clarity and consistency in deployment
scripts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a Databricks plugin for executing queries and managing
database connections.
- Added a migration to incorporate the Databricks plugin into existing
workspaces.
- **Bug Fixes**
- Ensured robust error handling in the Databricks plugin with clear
messaging for query execution failures.
- **Tests**
- Implemented tests to validate the behavior of the Databricks plugin
under various connection scenarios.
- **Documentation**
- Included configuration properties for the Databricks plugin setup.
- **Refactor**
- Added specific error types and messages for the Databricks plugin to
improve debugging and user feedback.
- **Chores**
- Modified the Java runtime environment settings to support the new
plugin's requirements.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Arpit Mohan <arpit@appsmith.com>
What are we solving here?
1. Installing Java in the `Dockerfile` by using Adoptium's package
repositories is fragile since they've started blocking some IP addresses
used by GitHub Actions runners. We see a message like this:
```
Failed to fetch
https://packages.adoptium.net/artifactory/deb/pool/main/t/temurin-17/temurin-17-jdk_17.0.8.1.0+1_amd64.deb
403 Forbidden [IP: 146.75.107.42 443]
```
We're seeing more and more cases of these and PRs are getting blocked.
2. Installing Java via `apt` also installs other packages like X11
libraries, that aren't really relevant to our usage of Java. Yet, these
packages are present in our Docker image, and are the source of several
CVEs to be reported by scanners on our Docker image.
3. This will give us control over trusted CA certificates, which we can
now perform under `$TMP`, which aligns with our move towards supporting
readonly root filesystem. Which is essentially not write to anything in
the Docker image at runtime, except for under `/tmp` and
`/appsmith-stacks`. This will help us move in that direction.
When running with a custom `PORT` env variable, NGINX server will be
listening on this port. In the backend's startup script, `run-java.sh`,
we're checking for RTS being up or not, at `localhost`. So when the port
is not 80, then this will never succeed, because it'll be looking for
NGINX at the wrong port.
Instead, the fix here will make the backend startup script hit RTS
_directly_ on RTS server's own port, instead of going via NGINX. This
means it's independent of both the `PORT` env variable and the NGINX
server, and only dependent on RTS being up, which is really what we want
here.
Move the files that are copied into the Docker image, into an `fs`
folder, that reflects the folder structure of that in the image. This
means two things right away:
1. A single `COPY` instruction in `Dockerfile` is enough to copy all the
files to their places.
2. The structure of files in the repo reflects that in the Docker image.
This makes working with the files/folders and troubleshooting with them
much easier.
❗ Note: **There's actually only 3 files changed, rest are just moved.**
