upsun · flovntp · Oct 2, 2025 · Sep 8, 2025 · Sep 8, 2025 · Sep 8, 2025
diff --git a/.github/workflows/check-openapi-spec-update.yaml b/.github/workflows/check-openapi-spec-update.yaml
@@ -25,27 +25,27 @@ jobs:
             -   name: Download and patch OpenAPI spec
                 run: |
                     echo "Download OpenAPI spec..."
-                    wget -O ./schema/openapispec-platformsh.json https://proxy.upsun.com/docs/openapispec-platformsh.json
+                    wget -O ./schema/openapispec-upsun.json https://docs.upsun.com/api/openapispec-upsun.json
 
                     echo "Patch OpenAPI spec..."
-                    sed -i 's/HTTP access permissions/Http access permissions/g' ./schema/openapispec-platformsh.json
+                    sed -i 's/HTTP access permissions/Http access permissions/g' ./schema/openapispec-upsun.json
 
-            -   name: Patch openapispec-platformsh.yaml (add x-<info> for better generation)
+            -   name: Remove existing Api and Model Classes
                 run: |
-                    php templates/pre-processing/preprocess_openapi.php
+                    rm -Rf src/Api/*
+                    rm -Rf src/Model/*
+                    rm -Rf docs/*
+
+            -   name: Pre-process OpenApi specs 
+                run: |
+                    php templates/pre-processing/preprocess-schema.php
 
             -   name: Generate code (php)
                 uses: openapitools/openapi-generator-cli@v2
                 with:
                     generator: php
                     config-file: templates/php/config.yaml
-                    openapi-file: schema/openapispec-platformsh.json                    
-
-            -   name: Remove empty phpunit tests from OpenAPI Generator 
-                run: |
-                    if [ -d "./test" ]; then
-                        rm -Rf "./test"
-                    fi
+                    openapi-file: schema/openapispec-upsun-processed.json
 
             -   name: Create Pull Request if changes
                 uses: peter-evans/create-pull-request@v6
@@ -63,7 +63,6 @@ jobs:
                         report
                         automated pr
                     add-paths: |
-                        schema/openapispec-platformsh.json
                         src/
                         tests/
                         docs/

diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml
@@ -20,7 +20,17 @@ jobs:
                   tools: composer
 
             - name: Install Composer dependencies
-              run: composer install --prefer-dist --no-progress --no-suggest
+              run: composer install --prefer-dist --no-progress
 
-            - name: Run PHP lint (phpcs)
-              run: composer run lint
+            - name: PHPCS fix on generated Model and Api classes in src
+              run: |
+                composer run fix
+              continue-on-error: true
+
+            - name: Rector fix on generated Model and Api classes in src
+              run: |
+                composer run rector
+              continue-on-error: true
+
+#            - name: Run PHP lint (phpcs)
+#              run: composer run lint
diff --git a/.gitignore b/.gitignore
@@ -21,4 +21,4 @@ openapitools.json
 .openapi-generator/
 .openapi-generator-ignore
 git_push.sh
-schema/openapispec-platformsh-xreturn.json
+schema/openapispec-upsun-processed.json
diff --git a/README.md b/README.md
diff --git a/composer.json b/composer.json
@@ -1,6 +1,6 @@
 {
     "name": "upsun/upsun-sdk-php",
-    "description": "# Introduction  Platform.sh is a container-based Platform-as-a-Service. Our main API is simply Git. With a single `git push` and a couple of YAML files in your repository you can deploy an arbitrarily complex cluster. Every [**Project**](#tag/Project) can have multiple applications (PHP, Node.js, Python, Ruby, Go, etc.) and managed, automatically provisioned services (databases, message queues, etc.).  Each project also comes with multiple concurrent live staging/development [**Environments**](#tag/Environment). These ephemeral development environments are automatically created every time you push a new branch or create a pull request, and each has a full copy of the data of its parent branch, which is created on-the-fly in seconds.  Our Git implementation supports integrations with third party Git providers such as GitHub, Bitbucket, or GitLab, allowing you to simply integrate Platform.sh into your existing workflow.  ## Using the REST API  In addition to the Git API, we also offer a REST API that allows you to manage every aspect of the platform, from managing projects and environments, to accessing accounts and subscriptions, to creating robust workflows and integrations with your CI systems and internal services.  These API docs are generated from a standard **OpenAPI (Swagger)** Specification document which you can find here in [YAML](openapispec-platformsh.yaml) and in [JSON](openapispec-platformsh.json) formats.  This RESTful API consumes and produces HAL-style JSON over HTTPS, and any REST library can be used to access it. On GitHub, we also host a few API libraries that you can use to make API access easier, such as our [PHP API client](https://github.com/platformsh/platformsh-client-php) and our [JavaScript API client](https://github.com/platformsh/platformsh-client-js).  In order to use the API you will first need to have a Platform.sh account (we have a [free trial](https://accounts.platform.sh/platform/trial/general/setup) available) and create an API Token.  # Authentication  ## OAuth2  API authentication is done with OAuth2 access tokens.  ### API tokens  You can use an API token as one way to get an OAuth2 access token. This is particularly useful in scripts, e.g. for CI pipelines.  To create an API token, go to the \"API Tokens\" section of the \"Account Settings\" tab on the [Console](https://console.platform.sh).  To exchange this API token for an access token, a `POST` request must be made to `https://auth.api.platform.sh/oauth2/token`.  The request will look like this in cURL:  <pre> curl -u platform-api-user: \\     -d 'grant_type=api_token&amp;api_token=<em><b>API_TOKEN</b></em>' \\     https://auth.api.platform.sh/oauth2/token </pre>  This will return a \"Bearer\" access token that can be used to authenticate further API requests, for example:  <pre> {     \"access_token\": \"<em><b>abcdefghij1234567890</b></em>\",     \"expires_in\": 900,     \"token_type\": \"bearer\" } </pre>  ### Using the Access Token  To authenticate further API requests, include this returned bearer token in the `Authorization` header. For example, to retrieve a list of [Projects](#tag/Project) accessible by the current user, you can make the following request (substituting the dummy token for your own):  <pre> curl -H \"Authorization: Bearer <em><b>abcdefghij1234567890</b></em>\" \\     https://api.platform.sh/projects </pre>  # HAL Links  Most endpoints in the API return fields which defines a HAL (Hypertext Application Language) schema for the requested endpoint. The particular objects returns and their contents can vary by endpoint. The payload examples we give here for the requests do not show these elements. These links can allow you to create a fully dynamic API client that does not need to hardcode any method or schema.  Unless they are used for pagination we do not show the HAL links in the payload examples in this documentation for brevity and as their content is contextual (based on the permissions of the user).  ## _links Objects  Most endpoints that respond to `GET` requests will include a `_links` object in their response. The `_links` object contains a key-object pair labelled `self`, which defines two further key-value pairs:  * `href` - A URL string referring to the fully qualified name of the returned object. For many endpoints, this will be the direct link to the API endpoint on the region gateway, rather than on the general API gateway. This means it may reference a host of, for example, `eu-2.platform.sh` rather than `api.platform.sh`. * `meta` - An object defining the OpenAPI Specification (OAS) [schema object](https://swagger.io/specification/#schemaObject) of the component returned by the endpoint.  There may be zero or more other fields in the `_links` object resembling fragment identifiers beginning with a hash mark, e.g. `#edit` or `#delete`. Each of these keys refers to a JSON object containing two key-value pairs:  * `href` - A URL string referring to the path name of endpoint which can perform the action named in the key. * `meta` - An object defining the OAS schema of the endpoint. This consists of a key-value pair, with the key defining an HTTP method and the value defining the [operation object](https://swagger.io/specification/#operationObject) of the endpoint.  To use one of these HAL links, you must send a new request to the URL defined in the `href` field which contains a body defined the schema object in the `meta` field.  For example, if you make a request such as `GET /projects/abcdefghij1234567890`, the `_links` object in the returned response will include the key `#delete`. That object will look something like this fragment:  ``` \"#delete\": {     \"href\": \"/api/projects/abcdefghij1234567890\",     \"meta\": {         \"delete\": {             \"responses\": {                 . . . // Response definition omitted for space             },             \"parameters\": []         }     } } ```  To use this information to delete a project, you would then send a `DELETE` request to the endpoint `https://api.platform.sh/api/projects/abcdefghij1234567890` with no body or parameters to delete the project that was originally requested.  ## _embedded Objects  Requests to endpoints which create or modify objects, such as `POST`, `PATCH`, or `DELETE` requests, will include an `_embedded` key in their response. The object represented by this key will contain the created or modified object. This object is identical to what would be returned by a subsequent `GET` request for the object referred to by the endpoint.",
+    "description": "# Introduction  Upsun, formerly Platform.sh, is a container-based Platform-as-a-Service. Our main API is simply Git. With a single `git push` and a couple of YAML files in your repository you can deploy an arbitrarily complex cluster. Every [**Project**](#tag/Project) can have multiple applications (PHP, Node.js, Python, Ruby, Go, etc.) and managed, automatically provisioned services (databases, message queues, etc.).  Each project also comes with multiple concurrent live staging/development [**Environments**](#tag/Environment). These ephemeral development environments are automatically created every time you push a new branch or create a pull request, and each has a full copy of the data of its parent branch, which is created on-the-fly in seconds.  Our Git implementation supports integrations with third party Git providers such as GitHub, Bitbucket, or GitLab, allowing you to simply integrate Upsun into your existing workflow.  ## Using the REST API  In addition to the Git API, we also offer a REST API that allows you to manage every aspect of the platform, from managing projects and environments, to accessing accounts and subscriptions, to creating robust workflows and integrations with your CI systems and internal services.  These API docs are generated from a standard **OpenAPI (Swagger)** Specification document which you can find here in [YAML](openapispec-upsun.yaml) and in [JSON](openapispec-upsun.json) formats.  This RESTful API consumes and produces HAL-style JSON over HTTPS, and any REST library can be used to access it. On GitHub, we also host a few API libraries that you can use to make API access easier, such as our [PHP API client](https://github.com/upsun/upsun-sdk-php).  In order to use the API you will first need to have an [Upsun account](https://auth.upsun.com/register/)  and [create an API Token](https://docs.upsun.com/anchors/cli/api-token/).  # Authentication  ## OAuth2  API authentication is done with OAuth2 access tokens.  ### API tokens  You can use an API token as one way to get an OAuth2 access token. This is particularly useful in scripts, e.g. for CI pipelines.  To create an API token, go to the \"API Tokens\" section of the \"Account Settings\" tab on the [Console](https://console.upsun.com).  To exchange this API token for an access token, a `POST` request must be made to `https://auth.upsun.com/oauth2/token`.  The request will look like this in cURL:  <pre> curl -u platform-api-user: \\     -d 'grant_type=api_token&amp;api_token=<em><b>API_TOKEN</b></em>' \\     https://auth.upsun.com/oauth2/token </pre>  This will return a \"Bearer\" access token that can be used to authenticate further API requests, for example:  <pre> {     \"access_token\": \"<em><b>abcdefghij1234567890</b></em>\",     \"expires_in\": 900,     \"token_type\": \"bearer\" } </pre>  ### Using the Access Token  To authenticate further API requests, include this returned bearer token in the `Authorization` header. For example, to retrieve a list of [Projects](#tag/Project) accessible by the current user, you can make the following request (substituting the dummy token for your own):  <pre> curl -H \"Authorization: Bearer <em><b>abcdefghij1234567890</b></em>\" \\     https://api.upsun.com/projects </pre>  # HAL Links  Most endpoints in the API return fields which defines a HAL (Hypertext Application Language) schema for the requested endpoint. The particular objects returns and their contents can vary by endpoint. The payload examples we give here for the requests do not show these elements. These links can allow you to create a fully dynamic API client that does not need to hardcode any method or schema.  Unless they are used for pagination we do not show the HAL links in the payload examples in this documentation for brevity and as their content is contextual (based on the permissions of the user).  ## _links Objects  Most endpoints that respond to `GET` requests will include a `_links` object in their response. The `_links` object contains a key-object pair labelled `self`, which defines two further key-value pairs:  * `href` - A URL string referring to the fully qualified name of the returned object. For many endpoints, this will be the direct link to the API endpoint on the region gateway, rather than on the general API gateway. This means it may reference a host of, for example, `eu-2.platform.sh` rather than `api.upsun.com`. * `meta` - An object defining the OpenAPI Specification (OAS) [schema object](https://swagger.io/specification/#schemaObject) of the component returned by the endpoint.  There may be zero or more other fields in the `_links` object resembling fragment identifiers beginning with a hash mark, e.g. `#edit` or `#delete`. Each of these keys refers to a JSON object containing two key-value pairs:  * `href` - A URL string referring to the path name of endpoint which can perform the action named in the key. * `meta` - An object defining the OAS schema of the endpoint. This consists of a key-value pair, with the key defining an HTTP method and the value defining the [operation object](https://swagger.io/specification/#operationObject) of the endpoint.  To use one of these HAL links, you must send a new request to the URL defined in the `href` field which contains a body defined the schema object in the `meta` field.  For example, if you make a request such as `GET /projects/abcdefghij1234567890`, the `_links` object in the returned response will include the key `#delete`. That object will look something like this fragment:  ``` \"#delete\": {     \"href\": \"/api/projects/abcdefghij1234567890\",     \"meta\": {         \"delete\": {             \"responses\": {                 . . . // Response definition omitted for space             },             \"parameters\": []         }     } } ```  To use this information to delete a project, you would then send a `DELETE` request to the endpoint `https://api.upsun.com/api/projects/abcdefghij1234567890` with no body or parameters to delete the project that was originally requested.  ## _embedded Objects  Requests to endpoints which create or modify objects, such as `POST`, `PATCH`, or `DELETE` requests, will include an `_embedded` key in their response. The object represented by this key will contain the created or modified object. This object is identical to what would be returned by a subsequent `GET` request for the object referred to by the endpoint.",
     "keywords": [
         "openapitools",
         "openapi-generator",
@@ -43,21 +43,26 @@
         "nyholm/psr7": "^1.8"
     },
     "require-dev": {
-        "phpunit/phpunit": "^8.0 || ^9.0",
         "friendsofphp/php-cs-fixer": "^3.5",
         "guzzlehttp/guzzle": "^7.0",
         "php-http/guzzle7-adapter": "^1.0",
+        "phpunit/phpunit": "^8.0 || ^9.0",
+        "rector/rector": "*",
         "squizlabs/php_codesniffer": "^3.13"
     },
     "autoload": {
         "psr-4": { "Upsun\\" : "src/" }
     },
     "autoload-dev": {
-        "psr-4": { "Upsun\\Test\\" : "test/" }
+        "psr-4": {
+            "Upsun\\Test\\" : "tests/",
+            "Upsun\\Test\\Core\\" : "tests/Core/"
+        }
     },
     "prefer-stable": true,
     "scripts": {
-        "lint": "phpcs --standard=PSR12 src/Core/Tasks",
-        "fix": "phpcbf --standard=PSR12 src/Core/Tasks"
+        "lint": "phpcs --standard=PSR12 src/",
+        "fix": "phpcbf --standard=PSR12 src/ || true",
+        "rector": "vendor/bin/rector process src || true"
     }
 }