From ae0d4cb117ca12a718f47b04bd0ba12284630363 Mon Sep 17 00:00:00 2001 From: kathweinschenkprophecy Date: Thu, 21 Nov 2024 15:05:08 -0500 Subject: [PATCH 1/2] standardize GitHub (#445) --- docs/SQL/gems/Transformations/aggregate.md | 2 +- docs/concepts/concepts.md | 2 +- docs/concepts/copilot/copilot.md | 6 ++-- docs/concepts/project/project.md | 2 +- .../prophecy-build-tool/pbt-github-actions.md | 20 ++++++------- .../prophecy-build-tool/pbt-jenkins.md | 28 +++++++++---------- .../prophecy-build-tool.md | 4 +-- docs/deployment/use-external-release-tags.md | 2 +- .../getting-started-sql-snowflake.md | 10 +++---- .../getting-started-with-low-code-sql.md | 4 +-- docs/metadata/pull-request-templates.md | 4 +-- docs/tutorials/videos/schedule-pipeline.md | 2 +- 12 files changed, 43 insertions(+), 43 deletions(-) diff --git a/docs/SQL/gems/Transformations/aggregate.md b/docs/SQL/gems/Transformations/aggregate.md index 044956f926..c5d7925c50 100644 --- a/docs/SQL/gems/Transformations/aggregate.md +++ b/docs/SQL/gems/Transformations/aggregate.md @@ -63,7 +63,7 @@ Now let's see how to configure the `payment_methods` variable. ![4](../img/Snow4.6.4_Aggregate.png) 1. Click **Config** to open the configuration screen. -2. We see the option to apply a configuration at several different **levels:** apply to the entire Model, all the Models in the Github folder, or all the Models in the Project. Here we can see there are Configurations that apply to this particular `Orders` Model. +2. We see the option to apply a configuration at several different **levels:** apply to the entire Model, all the Models in the GitHub folder, or all the Models in the Project. Here we can see there are Configurations that apply to this particular `Orders` Model. 3. See the list of [DBT Defined Configs](https://docs.getdbt.com/reference/configs-and-properties). These are configs every user could employ with their DBT Projects, such as whether to materialize the model as table, view, ephemeral, or incremental. Click the dropdown to select the config of interest, then enter the appropriate value. Hover over the "i" icon for a short description of each DBT Config. 4. See the list of user-defined **Variables**. In our HelloWorld_SQL project, the `payment_methods` variable has been defined with the four **values** shown. 5. Click **Save** after editing the Config for the Model, Folder, or Project. diff --git a/docs/concepts/concepts.md b/docs/concepts/concepts.md index 39428a026a..3365a7f073 100644 --- a/docs/concepts/concepts.md +++ b/docs/concepts/concepts.md @@ -19,7 +19,7 @@ A **project** contains ### Project is Code on Git -A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on Github or a folder in a repository. +A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on GitHub or a folder in a repository. ![Project is code](img/project_is_code.png) diff --git a/docs/concepts/copilot/copilot.md b/docs/concepts/copilot/copilot.md index 4098be2d62..32c859d637 100644 --- a/docs/concepts/copilot/copilot.md +++ b/docs/concepts/copilot/copilot.md @@ -45,15 +45,15 @@ For more details, see [Enable Data Copilot](/concepts/copilot/enable-data-copilo ### -#### How is Prophecy Copilot different than Github Copilot? +#### How is Prophecy Copilot different than GitHub Copilot? -Github Copilot is a great tool to boost productivity and extend the reach of the coding community. However, not every problem is solved with direct coding. More importantly, users need a Copilot with some context of the interesting data. +GitHub Copilot is a great tool to boost productivity and extend the reach of the coding community. However, not every problem is solved with direct coding. More importantly, users need a Copilot with some context of the interesting data. For teams of analysts, data platform providers, or line-of-business users, the pain points are not resolved by teaching every team member how to code. Data Copilot empowers less technical users because they don’t have to code. Importantly, technical and coding users benefit from Data Copilot because visual Pipelines are easier to understand, explain, and leverage. Prophecy’s Data Copilot boosts the productivity of the business user and the more technical coding team members. When all of these data practitioners reach for an AI assistant, they’ll need one specific to the data space. For example, the assistant should collect metadata from the data warehouse, catalog, or storage provider. Prophecy Data Copilot has the context of your data, and it can guide Pipeline and Model development by suggesting which Datasets to use and how to use them. -Github Copilot and Prophecy Data Copilot are both excellent tools to boost productivity, but Prophecy Data Copilot is accessible to a larger user base and can make data suggestions because it maintains data context. +GitHub Copilot and Prophecy Data Copilot are both excellent tools to boost productivity, but Prophecy Data Copilot is accessible to a larger user base and can make data suggestions because it maintains data context. #### Which Datasets are accessible to Prophecy Data Copilot? diff --git a/docs/concepts/project/project.md b/docs/concepts/project/project.md index 9aec5b433c..3c46b56e89 100644 --- a/docs/concepts/project/project.md +++ b/docs/concepts/project/project.md @@ -18,7 +18,7 @@ A **project** contains ## Projects are Code on Git -A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on Github or a folder in a repository. +A **project** is **code** on **Git**. This means that within a project, the business logic of all the assets including _Pipelines_/_Models_, _Datasets_, and _Jobs_ is stored as code on Git. This might be a repository on GitHub or a folder in a repository. ![Project is code](../img/project_is_code.png) diff --git a/docs/deployment/prophecy-build-tool/pbt-github-actions.md b/docs/deployment/prophecy-build-tool/pbt-github-actions.md index 5ba3a6b751..d8c7ce18dc 100644 --- a/docs/deployment/prophecy-build-tool/pbt-github-actions.md +++ b/docs/deployment/prophecy-build-tool/pbt-github-actions.md @@ -1,7 +1,7 @@ --- -title: PBT on Github Actions +title: PBT on GitHub Actions id: prophecy-build-tool-github-actions -description: Example usage of Prophecy Build Tool on Github Actions +description: Example usage of Prophecy Build Tool on GitHub Actions sidebar_position: 5 tags: - metadata @@ -15,31 +15,31 @@ tags: - cicd --- -## [Example Github Repo](https://github.com/prophecy-samples/external-cicd-template) +## [Example GitHub Repo](https://github.com/prophecy-samples/external-cicd-template) ## Integrating with GitHub Actions -PBT can be integrated with your own CI/CD solution to build, test and deploy Prophecy code. The steps for setting up PBT with Github Actions on your repository containing a Prophecy project are mentioned below. +PBT can be integrated with your own CI/CD solution to build, test and deploy Prophecy code. The steps for setting up PBT with GitHub Actions on your repository containing a Prophecy project are mentioned below. ### Pre-requisite -- A Prophecy project that is currently hosted in a Github repository +- A Prophecy project that is currently hosted in a GitHub repository ### Setting up environment variables and secrets PBT requires environment variables **DATABRICKS_URL** and **DATABRICKS_TOKEN** to be set for complete functionality. -The **DATABRICKS_TOKEN** that needs to be used can be set as a secret inside the Github repository of the project. +The **DATABRICKS_TOKEN** that needs to be used can be set as a secret inside the GitHub repository of the project. Steps: -- Go to Settings > Secrets > Actions from the Github repository menu +- Go to Settings > Secrets > Actions from the GitHub repository menu - Click ‘New Repository secret’ - Add the secret with name DATABRICKS_TOKEN and value of the Databricks token to be used by PBT. Screenshot after setting DATABRICKS_TOKEN secret: -![Github Actions Secret addition](img/pbt-github-secret.png) +![GitHub Actions Secret addition](img/pbt-github-secret.png) -The environment variables can now be all set within the Github actions YML file as follows: +The environment variables can now be all set within the GitHub actions YML file as follows: ```yaml env: @@ -63,7 +63,7 @@ To setup a workflow to build, run all unit tests and then deploy the built jar ( - Add the below contents to **exampleWorkflow.yml** ```yaml - name: Example CI/CD with Github actions + name: Example CI/CD with GitHub actions on: push: branches: - "prod" diff --git a/docs/deployment/prophecy-build-tool/pbt-jenkins.md b/docs/deployment/prophecy-build-tool/pbt-jenkins.md index 7ff77ed6dc..fdf1b22ea0 100644 --- a/docs/deployment/prophecy-build-tool/pbt-jenkins.md +++ b/docs/deployment/prophecy-build-tool/pbt-jenkins.md @@ -15,7 +15,7 @@ tags: - jenkins --- -## [Example Github Repo](https://github.com/prophecy-samples/external-cicd-template) +## [Example GitHub Repo](https://github.com/prophecy-samples/external-cicd-template) ## Context of the Jenkins CI/CD Example @@ -23,7 +23,7 @@ In this section we will explore how to set up separate "testing" and "deploying" `prod`, `qa`, `develop`. Each of these three branches represents a different Databricks Workspace environment. We want to be able to test and deploy our Pipelines into each of these three workspaces during our release workflow. -The release process on Github is defined as merging and testing to branches in the following +The release process on GitHub is defined as merging and testing to branches in the following order: `feature-branch` > `develop` > `qa` > `prod` ![branch_protection_checks_example.png](img%2Fbranch_protection_checks_example.png) @@ -54,9 +54,9 @@ You should have access to: The following plugins were used for this example: -- [Github Pull Request Builder](https://plugins.jenkins.io/ghprb/) +- [GitHub Pull Request Builder](https://plugins.jenkins.io/ghprb/) - for the build/test Job -- [Github](https://plugins.jenkins.io/github/) +- [GitHub](https://plugins.jenkins.io/github/) - for the deploy Job :::caution @@ -101,10 +101,10 @@ This Pipeline uses PBT to validate the pipelines and run all Prophecy unit tests - Create a Jenkins Pipeline ![jenkins-pipeline-type.png](img%2Fjenkins-pipeline-type.png) -- Configure the Github Project URL -- Choose Github Pull Request Builder as the trigger type. -- Provide credentials to Github - - creating a fine-grained Personal Acces Token (PAT) in Github. The PAT should be +- Configure the GitHub Project URL +- Choose GitHub Pull Request Builder as the trigger type. +- Provide credentials to GitHub + - creating a fine-grained Personal Acces Token (PAT) in GitHub. The PAT should be scoped to yourself or your Organization, have access to the repository containing the Prophecy project, and appropriate permissions: ![github-pat-permissions.png](img%2Fgithub-pat-permissions.png) @@ -120,11 +120,11 @@ This Pipeline uses PBT to validate the pipelines and run all Prophecy unit tests ### Testing Pipeline - Trigger -We use the [Github Pull Request Builder](https://plugins.jenkins.io/ghprb/) to trigger any time there is a new pull request or a change +We use the [GitHub Pull Request Builder](https://plugins.jenkins.io/ghprb/) to trigger any time there is a new pull request or a change on a pull request (comment or new commit) to our special branches: `develop`, `qa`, `prod`. -By providing Github credentials to the GHPRB plugin it will be able to automatically -create webhooks in Github. +By providing GitHub credentials to the GHPRB plugin it will be able to automatically +create webhooks in GitHub.
Refer to this image for all settings. @@ -217,8 +217,8 @@ This Pipeline uses PBT to deploy the Prophecy Pipelines to their appropriate Fab - Create a Jenkins Pipeline ![jenkins-pipeline-type.png](img%2Fjenkins-pipeline-type.png) -- Choose "Github hook for GITScm polling" as the trigger. -- Choose "Pipeline from SCM" with our Github repo as the repository +- Choose "GitHub hook for GITScm polling" as the trigger. +- Choose "Pipeline from SCM" with our GitHub repo as the repository - Choose the branches to trigger on (`develop`, `qa`, `prod`) - Point the "Script path" [to our Jenkinsfile](#deploy-pipeline---pipeline-code) containing the deploy logic @@ -231,7 +231,7 @@ This Pipeline uses PBT to deploy the Prophecy Pipelines to their appropriate Fab ### Deploy Pipeline - Trigger -Set up a simple webhook trigger for this Job inside of Github. +Set up a simple webhook trigger for this Job inside of GitHub. - Navigate to `Settings > Webhooks > Add Webhook` - Create a new webhook like this: diff --git a/docs/deployment/prophecy-build-tool/prophecy-build-tool.md b/docs/deployment/prophecy-build-tool/prophecy-build-tool.md index 261b103a6f..d0f4c6ed36 100644 --- a/docs/deployment/prophecy-build-tool/prophecy-build-tool.md +++ b/docs/deployment/prophecy-build-tool/prophecy-build-tool.md @@ -14,7 +14,7 @@ tags: --- **Prophecy-built-tool** (PBT) allows you to quickly build, test and deploy projects generated by Prophecy (your standard Spark Scala and -PySpark Pipelines) to integrate with your own CI / CD (e.g. Github Actions), build system (e.g. Jenkins), and +PySpark Pipelines) to integrate with your own CI / CD (e.g. GitHub Actions), build system (e.g. Jenkins), and orchestration (e.g. Databricks Workflows). ## Features (v1.1.0) @@ -43,7 +43,7 @@ pip3 install prophecy-build-tool ## Integration Examples -### [Github Actions](pbt-github-actions.md) +### [GitHub Actions](pbt-github-actions.md) ### [Jenkins](pbt-jenkins.md) diff --git a/docs/deployment/use-external-release-tags.md b/docs/deployment/use-external-release-tags.md index ee245d2933..4dc9d1413f 100644 --- a/docs/deployment/use-external-release-tags.md +++ b/docs/deployment/use-external-release-tags.md @@ -14,7 +14,7 @@ tags: - cicd --- -If you use external CI-CD tools like Github or Jenkins to merge and release your projects, you can use release tags from those tools in Prophecy for deployment and dependencies. Once you've deployed the tags via Prophecy, you can add them as a dependency to your Projects. +If you use external CI-CD tools like GitHub or Jenkins to merge and release your projects, you can use release tags from those tools in Prophecy for deployment and dependencies. Once you've deployed the tags via Prophecy, you can add them as a dependency to your Projects. Any externally created release tag that you pull into Prophecy is visible on Releases and Deployments. diff --git a/docs/getting-started/getting-started-sql-snowflake.md b/docs/getting-started/getting-started-sql-snowflake.md index 02b75ed74f..71e29e807c 100644 --- a/docs/getting-started/getting-started-sql-snowflake.md +++ b/docs/getting-started/getting-started-sql-snowflake.md @@ -21,7 +21,7 @@ This quick-start gets you up and running with **building data transformations us #### You will need - Snowflake Account -- Github Account (recommended) +- GitHub Account (recommended) ## 1. Setup Prophecy account @@ -111,7 +111,7 @@ Once the basic project information is filled out, it’s time to configure the G ![Git Repository Connection](img/Snow3.2_connectToGit.png) -You'll see two options to connect to Git. **(1) Prophecy Managed Git Credentials** are not supported for this use case. You will need a Github account for this getting started guide. If you don't have one, create one by following [these instructions](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github). Select **(2) Connect to External Git** to connect to your external Git account. +You'll see two options to connect to Git. **(1) Prophecy Managed Git Credentials** are not supported for this use case. You will need a GitHub account for this getting started guide. If you don't have one, create one by following [these instructions](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github). Select **(2) Connect to External Git** to connect to your external Git account. ### 3.1 Connect to external Git repository @@ -121,13 +121,13 @@ When connecting to external Git repositories, you have to first setup a Git conn #### 3.1.1 Connecting with GitHub -![Connect With Github](img/Snow3.3_LinkAndAuthorize.png) +![Connect With GitHub](img/Snow3.3_LinkAndAuthorize.png) -If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t have an account, you can create one at [Github.com](http://github.com). +If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t have an account, you can create one at [GitHub.com](http://github.com). 1. **Alias** - Each Git connection in Prophecy starts with an **Alias** that’s going to be used to allow you to identify the right Git account. In most cases, this can be left as default. -2. **Login with Github** - redirects you to a GitHub login page (if you're not yet logged in). +2. **Login with GitHub** - redirects you to a GitHub login page (if you're not yet logged in). 3. **Sign in** - or create a new GitHub account. diff --git a/docs/getting-started/getting-started-with-low-code-sql.md b/docs/getting-started/getting-started-with-low-code-sql.md index a8d78b8a49..fd01a577ea 100644 --- a/docs/getting-started/getting-started-with-low-code-sql.md +++ b/docs/getting-started/getting-started-with-low-code-sql.md @@ -132,9 +132,9 @@ To see a dropdown of repositories accessible to the Git user, be sure to connect #### 3.2.1 Connecting with GitHub -![Connect With Github](img/3-4-connect-with-github.png) +![Connect With GitHub](img/3-4-connect-with-github.png) -If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t, you can create an account at [Github.com](http://github.com). +If you have an existing GitHub account this process is very simple, thanks to Prophecy’s strong OAuth GitHub integration. If you don’t, you can create an account at [GitHub.com](http://github.com). Each Git connection in Prophecy starts with an **(1) Alias** that’s going to be used to allow you to identify the right Git account. In most cases, this can be left as default. With that set click **(2) Login** with GitHub which will redirect you to a GitHub login page (if you’re not yet logged in). Enter your details and **(3) Sign in** or create a new account. From there, you’ll be asked to approve Prophecy as a valid application. diff --git a/docs/metadata/pull-request-templates.md b/docs/metadata/pull-request-templates.md index 4fd5660f31..a74ad54be3 100644 --- a/docs/metadata/pull-request-templates.md +++ b/docs/metadata/pull-request-templates.md @@ -28,7 +28,7 @@ The `{{source}}` variable represents the active development branch, and the represents the base branch to which the feature/development branches need to be merged to , eg. `main`. -Example template for a Github repository: +Example template for a GitHub repository: ```shell https://github.com/exampleOrg/exampleRepo/compare/{{destination}}...{{source}}?expand=1 @@ -44,7 +44,7 @@ https://github.com/exampleOrg/exampleRepo/compare/main...feature?expand=1 :::info The pull request template would be automatically generated and populated in the `Advanced` > `Pull Request Template` settings depending on your configured external Git provider. This auto-generation is -currently being done for Github, Github Enterprise, Gitlab, Gitlab Enterprise, BitBucket and Azure Devops repositories. +currently being done for GitHub, GitHub Enterprise, Gitlab, Gitlab Enterprise, BitBucket and Azure Devops repositories. Users will be able to edit the autogenerated templates as well. ::: An example of an autogenerated PR template for a project linked with GitHub: diff --git a/docs/tutorials/videos/schedule-pipeline.md b/docs/tutorials/videos/schedule-pipeline.md index a7cbdb4f6a..5a1c2985c3 100644 --- a/docs/tutorials/videos/schedule-pipeline.md +++ b/docs/tutorials/videos/schedule-pipeline.md @@ -57,7 +57,7 @@ Now the main branch contains the Pipeline and the scheduled Job. Let’s release We have released the Job to run in Databricks workflows. At the same time, We have created a versioned release of our codebase. So, our Pipeline and schedule are now on the main branch, and a versioned tag has been created. [CI/CD](https://fast.wistia.net/embed/iframe/dvayf1k9us?wtime=4m9s?seo=false?videoFoam=true) -You’re probably curious if Prophecy’s deployments integrate with your jenkins, Github actions, or existing deployment toolset. YES! Use Prophecy Build tool to integrate with these in-house CI/CD tools. +You’re probably curious if Prophecy’s deployments integrate with your jenkins, GitHub actions, or existing deployment toolset. YES! Use Prophecy Build tool to integrate with these in-house CI/CD tools. [Prophecy Build Tool](https://fast.wistia.net/embed/iframe/dvayf1k9us?wtime=4m9s?seo=false?videoFoam=true) (available [here](https://Github.com/SimpleDataLabsInc/Prophecy-build-tool)) From 68b07c491ac0fe9f5ff64aa43ac462a5bc5bc978 Mon Sep 17 00:00:00 2001 From: Alexander Ahn Date: Fri, 22 Nov 2024 12:25:45 -0800 Subject: [PATCH 2/2] Add Extended Maintenance Release info to docs (#443) * Update version_chart.md * Update version_chart.md * Add Prophecy versions support page * Fix broken links * Update prophecy-libs.md * removing unused arg * Update versions_support.md * Update version_chart.md removed parentheses * Update docs/release_notes/version_chart/versions_support.md wordsmithing Co-authored-by: kathweinschenkprophecy * Update docs/release_notes/version_chart/versions_support.md Co-authored-by: kathweinschenkprophecy * Update versions_support.md --------- Co-authored-by: RJ Co-authored-by: RJ <55955360+neontty@users.noreply.github.com> Co-authored-by: kathweinschenkprophecy --- .../enable-pipeline-monitoring.md | 2 +- docs/concepts/fabrics/prophecy-libs.md | 2 +- .../version_chart/_category_.json | 6 ++ .../{ => version_chart}/version_chart.md | 5 +- .../version_chart/versions_support.md | 56 +++++++++++++++++++ scripts/find_versions_from_git_tags.py | 3 +- 6 files changed, 68 insertions(+), 6 deletions(-) create mode 100644 docs/release_notes/version_chart/_category_.json rename docs/release_notes/{ => version_chart}/version_chart.md (98%) create mode 100644 docs/release_notes/version_chart/versions_support.md diff --git a/docs/Spark/pipeline-monitoring/enable-pipeline-monitoring.md b/docs/Spark/pipeline-monitoring/enable-pipeline-monitoring.md index 353ef61514..67bd3ef2f5 100644 --- a/docs/Spark/pipeline-monitoring/enable-pipeline-monitoring.md +++ b/docs/Spark/pipeline-monitoring/enable-pipeline-monitoring.md @@ -27,7 +27,7 @@ You can check your **ProphecyLibsPython** version under **Dependencies**. If you have uncommitted changes in your Pipelines, you may be prompted to either **Commit & Save** or **Save Without Committing**. The update will affect all Pipelines in your Project. -For an up-to-date list of Prophecy versions and libraries, see [Version Chart](/docs/release_notes/version_chart.md). +For an up-to-date list of Prophecy versions and libraries, see [Version Chart](/docs/release_notes/version_chart/version_chart.md). ## Turn on the Pipeline Monitoring flag diff --git a/docs/concepts/fabrics/prophecy-libs.md b/docs/concepts/fabrics/prophecy-libs.md index 047b2cf7b9..5973f14415 100644 --- a/docs/concepts/fabrics/prophecy-libs.md +++ b/docs/concepts/fabrics/prophecy-libs.md @@ -17,7 +17,7 @@ You can see which Prophecy Libs version is running on your Spark cluster by chec Prophecy libs version in the Fabric cluster -For a list of the latest versions, see [Version Chart](/docs/release_notes/version_chart.md). +For a list of the latest versions, see [Version Chart](/docs/release_notes/version_chart/version_chart.md). ## Functionality diff --git a/docs/release_notes/version_chart/_category_.json b/docs/release_notes/version_chart/_category_.json new file mode 100644 index 0000000000..94866f262b --- /dev/null +++ b/docs/release_notes/version_chart/_category_.json @@ -0,0 +1,6 @@ +{ + "label": "Version Chart", + "position": 3, + "collapsible": true, + "collapsed": true +} diff --git a/docs/release_notes/version_chart.md b/docs/release_notes/version_chart/version_chart.md similarity index 98% rename from docs/release_notes/version_chart.md rename to docs/release_notes/version_chart/version_chart.md index 2135e4925b..2608f8e069 100644 --- a/docs/release_notes/version_chart.md +++ b/docs/release_notes/version_chart/version_chart.md @@ -15,13 +15,14 @@ Check to make sure the Spark version and Scala version of your Prophecy Scala Li of your cluster! ::: -:::info -Query this table using the following API and your ([personal access token](..%2Fmetadata%2FprophecyAPI.md)): +You can query this table using the following API and your [personal access token](/docs/metadata/prophecyAPI.md): ```bash curl --header 'X-Auth-Token: $PROPHECY_PAT' --location https://app.prophecy.io/api/editor/plibVersions ``` +:::note +Prophecy versions that are labeled with `EM` are Extended Maintenance releases. For more information, see [Prophecy versions support](/docs/release_notes/version_chart/versions_support.md). ::: | Prophecy version | [Prophecy Scala libs](https://mvnrepository.com/artifact/io.prophecy/prophecy-libs) | [Prophecy Python libs](https://pypi.org/project/prophecy-libs/) | Release Date | End-of-support Date | diff --git a/docs/release_notes/version_chart/versions_support.md b/docs/release_notes/version_chart/versions_support.md new file mode 100644 index 0000000000..054465dc7d --- /dev/null +++ b/docs/release_notes/version_chart/versions_support.md @@ -0,0 +1,56 @@ +--- +title: Prophecy versions support +id: versions_support +description: Prophecy versions support +sidebar_position: 1 +tags: [compatibility, matrix, version, chart, library, plib, plibs] +--- + +This page describes the Prophecy versioning system, version types, and version lifecycles. + +## Release version system + +The following table shows details of the different Prophecy version types. + +| Version type | Example | Frequency (approx.) | End-of-support | +| --------------------------------- | ------------- | ------------------- | ---------------- | +| Extended Maintenance (EM) release | `v3.4.1.0 EM` | Every four months | After one year | +| Major | `v3.4.0.0` | Every four months | After six months | +| Minor | `v3.3.11.0` | Every three weeks | After six months | +| Patch | `v3.3.11.7` | When needed | After six months | + +## Extended Maintenance release + +Extended Maintenance (EM) releases provide you with a long-term support Prophecy version, along with the following benefits: + +- Upgraded third party libraries for robust security posture +- Full performance and scale testing to check resource guidance +- Direct upgrade path from a previous EM release to the next one +- One year of technical support and hotfixes for critical issues + +You can expect a new Extended Maintenance release two to six weeks after each Major release. + +### Required resources + +Extended Maintenance releases require additional resources, such as CPU and memory. Starting with `v3.4.1.0 EM`, SQL Sandbox is enabled, so every SQL Pipeline session will spin up an additional pod with the following configuration: + +- CPI: 500m +- Memory: 512Mi + +After upgrading to 3.4.1, you must enable SQL Sandbox Config in the UI by navigating to the **Sandbox Config** tab in the Config sub tab of the Admin Settings. + +`"sqlSandboxPoolSize"` must be set to a minimum of `2`. This parameter determines the number of pods that are kept in a ready state. You will need additional SQL Sandbox resources for each simultaneous user session. + +## Prophecy support lifecycles + +The following table describes the support stages for Prophecy versions. Prophecy supports GA versions for six months, unless the version is an Extended Maintenance (EM) release, which Prophecy supports for one year. For information on supported Prophecy versions, see [Version Chart](/docs/release_notes/version_chart/version_chart.md). + +Workloads on unsupported Prophecy versions may continue to run, but Prophecy doesn't provide support or fixes. + +### Prophecy version lifecycle + +| Phase | Description | +| -------------------------------------------------- | -------------------------------------------------------------------------------------------------- | +| GA, full support for Extended Maintenance releases | Critical stability and security fixes are backported only for EM releases. | +| End of support | If a version is unsupported, then workloads running on these versions receive no Prophecy support. | +| End of Life | Prophecy reserves the right to completely remove a release version at any time after support ends. | diff --git a/scripts/find_versions_from_git_tags.py b/scripts/find_versions_from_git_tags.py index 7a85c2f13f..7069a9d6fa 100644 --- a/scripts/find_versions_from_git_tags.py +++ b/scripts/find_versions_from_git_tags.py @@ -52,7 +52,7 @@ def get_versions_for_tag(repo, tag_name): def update_version_chart_file(docs_repo_path): - version_chart_file = os.path.join(docs_repo_path, "docs/release_notes/version_chart.md") + version_chart_file = os.path.join(docs_repo_path, "docs/release_notes/version_chart/version_chart.md") header_lines = [] delimiter = "" delimiter_regex = "-------------" @@ -102,7 +102,6 @@ def process_args(prophecy_repo_path, docs_repo_path, tag_name=None): parser.add_argument("--prophecy-repo-path", default='./prophecy/', help="Path to the prophecy Git repository") parser.add_argument("--docs-repo-path", default='./prophecy-docs/', help="Path to the docs Git repository") parser.add_argument("--tag", help="Process a specific tag (if omitted we process all that match semver structure)") - parser.add_argument("--output-path", help="absolute path for output file", default="./version_chart.md") args = parser.parse_args()