Schema merge requestshttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests2023-03-30T17:21:22Zhttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/468Continue build if dependency-maven-check failed2023-03-30T17:21:22ZYash DholakiaContinue build if dependency-maven-check failedContinue build if dependency-maven-check failed. It fails when nvd.nist is down.Continue build if dependency-maven-check failed. It fails when nvd.nist is down.M17 - Release 0.20Okoun-Ola Fabien HouetoOkoun-Ola Fabien Houetohttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/168Containerize the schema bootstrapping process2023-08-18T21:57:13ZAman VermaContainerize the schema bootstrapping processIn this MR, adding
- A Dockerfile for schema bootstrapping in azure
- A README file, instructing how to build and run a container manually using the Dockerfile
Updating-
The bootstrap related yaml file to containerize the bootstrap processIn this MR, adding
- A Dockerfile for schema bootstrapping in azure
- A README file, instructing how to build and run a container manually using the Dockerfile
Updating-
The bootstrap related yaml file to containerize the bootstrap processM9 - Release 0.12Aman VermaAman Vermahttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/21consuming new methods defined in BlobStore class2023-08-18T22:00:56ZAman Vermaconsuming new methods defined in BlobStore class
## All Submissions:
-------------------------------------
* [YES/NO] I have added an explanation of what changes in this merge do and why we should include it? YES
* [YES/NO] I have updated the documentation accordingly. YES
* [YES/NO/N...
## All Submissions:
-------------------------------------
* [YES/NO] I have added an explanation of what changes in this merge do and why we should include it? YES
* [YES/NO] I have updated the documentation accordingly. YES
* [YES/NO/NA] I have added tests to cover my changes. YES
* [YES/NO/NA] All new and existing tests passed. YES
* [YES/NO/NA] My code follows the code style of this project. YES
## What is the issue or story related to the change?
-------------------------------------
<!-- Please describe the current behavior that you are modifying, 'or' link to a relevant issue.
Feel free to add references to any design documents you might have shared with the team or any
related MR that you are building on top of. -->
High level design:
The BlobStore class container two types of methods for interacting with blob storage. One where we can supply the container name as parameter and other where it is not needed. Going forward, the second types of methods are being deprecated, hence updating all the blob storage related method calls to first type.
Issue: <!-- Link any __GitLab__ workitem(s) to this pull request. -->
N/A
<!-- Please add implementation details of current set of changes and how the code changes are
doing what they are expected to do. Are there any complex loops or designated code blocks that
should be elaborated? Is there some contextual knowledge that the reviewer should be aware of? -->
Change details:
1. Calling `*FromStorageContainer` methods instead of `*FromBlob` methods
2. Updated UTs.
3. Minor fixes: defining the `storage container name` in application.properties instead of hard coding it in code; reading the port number from environment variable rather than keeping it in properties file.
## Test coverage:
------------------
<!-- Mention unit test coverage of changes. -->
Unit test coverage: 89%
All integration tests passing locally.
## Does this introduce a breaking change?
-------------------------------------
- [YES/NO]
NO
<!-- If this introduces a breaking change, please describe the impact and migration path for existing applications below. -->
## Pending items
----------------
<!-- Are there changes that you'll introduce in upcoming MRs and hence did not add in this one? Next steps of your
feature can also be mentioned here. -->
Similar changes are required for WKS service
## Reviewer request
-------------------
- Please provide an ETA when you plan to review this MR. Write a comment to decline or provide an ETA.
- Block the MR if you feel there is less testing or no details in the MR
- Please cover the following aspects in the MR
-- Coding design: _\<Reviewer1>_
-- Backward Compatibility: _\<Reviewer2>_
-- Feature Logic: _\<Logic design\>_
-- _\<Any other context mention here>_
OR
-- _\<Component 1>_: _\<Reviewer1>_
-- _\<CosmosDB>_: _\<Reviewer2>_
-- _\<ServiceBus>_ _\<Reviewer3>_
-- _\<Mention any other component and owner>_
## Other information
-------------------------------------
<!-- Any other information that is important to this MR such as screenshots of how the component looks before and after the change. -->
FYI @kibattul , @polavishnu ,@danielscholl , @dkodeih , @harshit283M1 - Release 0.1Aman VermaAman Vermahttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/598Community implementation2023-11-20T10:08:16ZRustam Lotsmanenko (EPAM)rustam_lotsmanenko@epam.comCommunity implementation# Description:
Story: https://gitlab.opengroup.org/osdu/pmc/community-implementation/-/issues/8
More details about the solution: https://community.opengroup.org/osdu/documentation/-/wikis/Pluggable-approach-for-Mappers-and-Drivers
As ...# Description:
Story: https://gitlab.opengroup.org/osdu/pmc/community-implementation/-/issues/8
More details about the solution: https://community.opengroup.org/osdu/documentation/-/wikis/Pluggable-approach-for-Mappers-and-Drivers
As a part of the community implementation solution schema-gc module was refactored to the schema-core-plus module, in addition new pluggable approach for Drivers was used.
## What is the current behavior?
- We do not have the core-plus module.
- Drivers not pluggable, all dependencies bounded during the compile step.
## What is the new behavior?
- We have the core-plus module.
- Drivers are pluggable and could be attached to service during image build, not compile.
Key components of pluggable configuration:
1. Add spring boot loader to service dependencies to **core-plus** service pom.xml, in this MR this dependency was added to **schema-core-plus pom.xml**
~~~
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-loader</artifactId>
<version>2.7.15</version>
</dependency>
~~~
2. Update service configuration to use Properties launcher from spring boot loader as the main class, in the same **schema-core-plus pom.xml**:
~~~
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
...
<configuration>
<classifier>spring-boot</classifier>
<mainClass>
org.springframework.boot.loader.PropertiesLauncher
</mainClass>
</configuration>
...
~~~
2. Download plugin artifacts(jar files) before building a Docker image or running it locally. The location could be any, the only requirement is to be accessible for running env or Docker image build:
~~~
- mvn dependency:copy -DrepoUrl=$OSM_PACKAGE_REGISTRY_URL -Dartifact="org.opengroup.osdu:os-osm-postgres:$OSM_VERSION:jar:plugin" -Dtransitive=false -DoutputDirectory="./tmp"
- mvn dependency:copy -DrepoUrl=$OBM_PACKAGE_REGISTRY_URL -Dartifact="org.opengroup.osdu:os-obm-minio:$OBM_VERSION:jar:plugin" -Dtransitive=false -DoutputDirectory="./tmp"
- mvn dependency:copy -DrepoUrl=$OQM_PACKAGE_REGISRTY_URL -Dartifact="org.opengroup.osdu:os-oqm-rabbitmq:$OQM_VERSION:jar:plugin" -Dtransitive=false -DoutputDirectory="./tmp"
~~~
3. Copy plugin jars into the Docker image:
~~~
COPY tmp/os-oqm-rabbitmq-*.jar plugins/oqm-rabbitmq.jar
COPY tmp/os-obm-minio-*.jar plugins/osm-minio.jar
COPY tmp/os-osm-postgres-*.jar plugins/osm-postgres.jar
~~~
4. Bundle service with plugins using run args, point to the directory with plugins, and point to the original main class:
~~~
java ...
...
-Dloader.path=plugins/ \
-Dloader.main=org.opengroup.osdu.legal.LegalApplication \
-jar /app/schema-${PROVIDER_NAME}.jar
~~~
# How to test:
Via integration tests.
# Changes include:
- [x] Refactor (a non-breaking change that improves code maintainability).
- [ ] Bugfix (a non-breaking change that solves an issue).
- [x] New feature (a non-breaking change that adds functionality).
- [ ] Breaking change (a change that is not backward-compatible and/or changes current functionality).
# Changes in:
- [x] Common code
# Dev Checklist:
- [ ] Added Unit Tests, wherever applicable.
- [x] Updated the Readme, if applicable.
- [x] Existing Tests pass
- [x] Verified functionality locally
- [x] Self Reviewed my code for formatting and complex business logic.M22 - Release 0.25Rustam Lotsmanenko (EPAM)rustam_lotsmanenko@epam.comRustam Lotsmanenko (EPAM)rustam_lotsmanenko@epam.comhttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/145[Common-Code] Updating the interfaces by adding methods for handling public s...2023-08-18T21:57:29ZAman Verma[Common-Code] Updating the interfaces by adding methods for handling public schemasThis is the first MR for implementing ADR https://community.opengroup.org/osdu/platform/system/schema-service/-/issues/51
What's changing:
====
- In the aforementioned ADR, we proposed that creation of system schemas should be done via...This is the first MR for implementing ADR https://community.opengroup.org/osdu/platform/system/schema-service/-/issues/51
What's changing:
====
- In the aforementioned ADR, we proposed that creation of system schemas should be done via a different REST end point altogether rather than by specifying a certain data-partition-id in headers in the existing `/schema` API
- The new API does not accept data-partition-id header, hence all the processing of system schemas should be done independent of tenant-id (same as data-partition-id)
More details are listed in ADR.
Change details:
====
Building on top of the details mentioned in previous section, we need the provider interfaces to expose methods for system schemas. These methods would be similar to existing methods, except they won't accept data-partition-id (aka tenantId) as parameter. Additionally, the method name should clearly communicate that it deals with system schemas and not normal schemas.
cc: @polavishnu @harshit283 @preeti @gramdas @pbehede @akumar290M9 - Release 0.12Aman VermaAman Vermahttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/93Committing tutorial2023-08-18T21:58:21ZAbhishek Kumar (SLB)Committing tutorialM5 - Release 0.8Abhishek Kumar (SLB)Abhishek Kumar (SLB)https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/208Code coverage2023-08-18T21:56:43ZAalekh JainCode coverageTasks accomplished as part of this MR
1. Added the support for generating code coverage reports using `Jacoco`
2. Updated the settings for CI/CD pipelines (Under section General Pipelines) to capture the code coverage using the Test Cov...Tasks accomplished as part of this MR
1. Added the support for generating code coverage reports using `Jacoco`
2. Updated the settings for CI/CD pipelines (Under section General Pipelines) to capture the code coverage using the Test Coverage Parsing regex as: `Total.*?([0-9]{1,3})%`
3. Added code coverage badge for azure in the `README.md` corresponding to azure cloud provider.
Attached below are the screenshots of the code coverage captured through bade and in the pipeline stages -
1. ![image](/uploads/0c7917ca04e2b26de08e49c34df8ce5d/image.png)
2. ![image](/uploads/ccb5584e6be2ef6e43b8e3ad7210883a/image.png)M10 - Release 0.13https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/156Clean up script for deployment framework(GONRG-3087)2021-09-06T14:47:50ZRustam Lotsmanenko (EPAM)rustam_lotsmanenko@epam.comClean up script for deployment framework(GONRG-3087)M9 - Release 0.12Riabokon Stanislav(EPAM)[GCP]Riabokon Stanislav(EPAM)[GCP]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/166Cleanup datastore pin data-partiton-id (GONRG-3355)2021-09-22T11:07:55ZRustam Lotsmanenko (EPAM)rustam_lotsmanenko@epam.comCleanup datastore pin data-partiton-id (GONRG-3355)# Description:
Minor fix for clean up script
# Changes include:
- [x] Refactor (a non-breaking change that improves code maintainability).
# Changes in:
- [x] GCP# Description:
Minor fix for clean up script
# Changes include:
- [x] Refactor (a non-breaking change that improves code maintainability).
# Changes in:
- [x] GCPM9 - Release 0.12Riabokon Stanislav(EPAM)[GCP]Riabokon Stanislav(EPAM)[GCP]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/251Cleaning up System Schemas if conditions for Azure2022-03-15T13:16:45ZAbhishek ChowdhryCleaning up System Schemas if conditions for Azurehttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/520Cherry-pick 'ws-fixes for schema service' into release/0.222023-07-17T19:34:56ZChad LeongCherry-pick 'ws-fixes for schema service' into release/0.22**Original MR**: !504
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !504
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-504)M19 - Release 0.22David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/399Cherry-pick 'Upgrade Tomcat' into release/0.172022-10-06T18:22:35ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade Tomcat' into release/0.17**Original MR**: !395
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !395
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-395)M14 - Release 0.17David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/227Cherry-pick ' Upgrade Log4J to 2.17.1' into 'release/0.13'2022-02-04T14:35:00ZDavid Diederichd.diederich@opengroup.orgCherry-pick ' Upgrade Log4J to 2.17.1' into 'release/0.13'Original MR: !225Original MR: !225M10 - Release 0.13David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/573Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.24' into ...2023-10-17T11:33:01ZSrinivasan NarayananCherry-pick 'Upgrade First Party Library Dependencies for Release 0.24' into release/0.24**Original MR**: !572
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !572
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-572)M21 - Release 0.24David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/549Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into ...2023-09-05T19:30:23ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into release/0.23**Original MR**: !546
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !546
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-546)M20 - Release 0.23David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/524Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.22' into ...2023-07-18T07:40:24ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.22' into release/0.22**Original MR**: !522
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !522
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-522)M19 - Release 0.22David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/502Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.21' into ...2023-05-31T20:29:10ZChad LeongCherry-pick 'Upgrade First Party Library Dependencies for Release 0.21' into release/0.21**Original MR**: !498
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !498
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-498)M18 - Release 0.21David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/419Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.18' into ...2022-12-12T09:55:55ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.18' into release/0.18**Original MR**: !418
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !418
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-418)M15 - Release 0.18David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/326Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.15' into ...2022-06-20T19:51:09ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.15' into release/0.15Original MR: !311Original MR: !311M12 - Release 0.15David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/325Cherry-pick 'Upgrade Core IBM Library for Release 0.15' into release/0.152022-06-20T19:50:54ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade Core IBM Library for Release 0.15' into release/0.15Original MR: !320Original MR: !320M12 - Release 0.15David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.org