Merge branch 'next' into feat/vitest

readmeio · Sep 5, 2023 · 0071e90 · 0071e90
2 parents f3b9a5d + a7ebee3
commit 0071e90
Show file tree

Hide file tree

Showing 12 changed files with 29,563 additions and 16,557 deletions.
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
@@ -23,6 +23,12 @@ updates:
       - kanadgupta
     labels:
       - dependencies
+    groups:
+      minor-developent-deps:
+        dependency-type: 'development'
+        update-types:
+          - minor
+          - patch
     commit-message:
       prefix: chore(deps)
       prefix-development: chore(deps-dev)

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,3 +1,17 @@
+## [8.6.6](https://github.com/readmeio/rdme/compare/v8.6.5...v8.6.6) (2023-08-24)
+
+
+### Bug Fixes
+
+* **versions:** fix ability to set main version ([#872](https://github.com/readmeio/rdme/issues/872)) ([ba7ea03](https://github.com/readmeio/rdme/commit/ba7ea03a8eb63eab09ab40ad46352504a7dc0134))
+
+## [8.6.6-next.1](https://github.com/readmeio/rdme/compare/v8.6.5...v8.6.6-next.1) (2023-08-24)
+
+
+### Bug Fixes
+
+* **versions:** fix ability to set main version ([#872](https://github.com/readmeio/rdme/issues/872)) ([ba7ea03](https://github.com/readmeio/rdme/commit/ba7ea03a8eb63eab09ab40ad46352504a7dc0134))
+
 ## [8.6.5](https://github.com/readmeio/rdme/compare/v8.6.4...v8.6.5) (2023-08-21)
 
 

diff --git a/README.md b/README.md
@@ -390,12 +390,12 @@ rdme versions --version={project-version}
 rdme versions:create <version>
 ```
 
-If you wish to automate the process of creating a new project version, and not have the CLI prompt you for input, you can do so by supplying the necessary flags to `versions:create`.
+If you wish to automate the process of creating a new project version, and not have the CLI prompt you for input, you can do so by supplying the necessary flags to `versions:create`. The best way to ensure that you have supplied all the necessary flags is by running the command locally and verifying that the CLI does not prompt you.
 
-For example:
+For example, the following command contains all the flags to bypass the CLI prompts:
 
 ```sh
-rdme versions:create <version> --fork={version-fork} --main={true|false} --beta={true|false} --isPublic={true|false}
+rdme versions:create <version> --fork={version-fork} --main={true|false} --beta={true|false} --deprecated={true|false} --isPublic={true|false}
 ```
 
 See `rdme versions:create --help` for a full list of flags.
@@ -406,7 +406,7 @@ See `rdme versions:create --help` for a full list of flags.
 rdme versions:update <version>
 ```
 
-Like `versions:create`, if you wish to automate this process and not be blocked by CLI input, you can supply the necessary flags to this command. See `rdme versions:update --help` for more information.
+Like `versions:create`, if you wish to automate this process and not be blocked by CLI input, you can supply the necessary flags to this command. See `rdme versions:update --help` for a full list of flags.
 
 #### Delete a Version
 

diff --git a/__tests__/cmds/versions/create.test.ts b/__tests__/cmds/versions/create.test.ts
@@ -101,6 +101,34 @@ describe('rdme versions:create', () => {
     mockRequest.done();
   });
 
+  it('should create successfully a main version', async () => {
+    const newVersion = '1.0.1';
+
+    const mockRequest = getAPIMock()
+      .post('/api/v1/version', {
+        version: newVersion,
+        from: '1.0.0',
+        is_beta: false,
+        is_stable: true,
+      })
+      .basicAuth({ user: key })
+      .reply(201, { version: newVersion });
+
+    await expect(
+      createVersion.run({
+        key,
+        version: newVersion,
+        fork: version,
+        beta: 'false',
+        main: 'true',
+        isPublic: 'false',
+        deprecated: 'true',
+      }),
+    ).resolves.toBe(`Version ${newVersion} created successfully.`);
+
+    mockRequest.done();
+  });
+
   it('should catch any post request errors', async () => {
     const errorResponse = {
       error: 'VERSION_EMPTY',

diff --git a/__tests__/cmds/versions/update.test.ts b/__tests__/cmds/versions/update.test.ts
@@ -214,6 +214,41 @@ describe('rdme versions:update', () => {
     mockRequest.done();
   });
 
+  it('should update a version to be the main one', async () => {
+    const versionToChange = '1.1.0';
+    const renamedVersion = '1.1.0-update';
+
+    const updatedVersionObject = {
+      version: renamedVersion,
+      is_beta: false,
+      is_stable: true,
+    };
+
+    const mockRequest = getAPIMock()
+      .get(`/api/v1/version/${versionToChange}`)
+      .basicAuth({ user: key })
+      .reply(200, { version: versionToChange })
+      .get(`/api/v1/version/${versionToChange}`)
+      .basicAuth({ user: key })
+      .reply(200, { version: versionToChange })
+      .put(`/api/v1/version/${versionToChange}`, updatedVersionObject)
+      .basicAuth({ user: key })
+      .reply(201, updatedVersionObject);
+
+    await expect(
+      updateVersion.run({
+        key,
+        version: versionToChange,
+        newVersion: renamedVersion,
+        deprecated: 'true',
+        beta: 'false',
+        main: 'true',
+        isPublic: 'false',
+      }),
+    ).resolves.toBe(`Version ${versionToChange} updated successfully.`);
+    mockRequest.done();
+  });
+
   // Note: this test is a bit bizarre since the flag management
   // in our version commands is really confusing to follow.
   // I'm not sure if it's technically possible to demote a stable version
@@ -225,11 +260,12 @@ describe('rdme versions:update', () => {
     const updatedVersionObject = {
       version: renamedVersion,
       is_beta: true,
+      is_deprecated: true,
       is_hidden: true,
       is_stable: false,
     };
 
-    prompts.inject([renamedVersion, true]);
+    prompts.inject([renamedVersion, true, false, true]);
 
     const errorResponse = {
       error: 'VERSION_CANT_DEMOTE_STABLE',

diff --git a/__tests__/helpers/github-workflow-schema.json b/__tests__/helpers/github-workflow-schema.json
@@ -260,6 +260,31 @@
         { "$ref": "#/definitions/name" }
       ]
     },
+    "matrix": {
+      "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix",
+      "description": "A build matrix is a set of different configurations of the virtual environment. For example you might run a job against more than one supported version of a language, operating system, or tool. Each configuration is a copy of the job that runs and reports a status.\nYou can specify a matrix by supplying an array for the configuration options. For example, if the GitHub virtual environment supports Node.js versions 6, 8, and 10 you could specify an array of those versions in the matrix.\nWhen you define a matrix of operating systems, you must set the required runs-on keyword to the operating system of the current job, rather than hard-coding the operating system name. To access the operating system name, you can use the matrix.os context parameter to set runs-on. For more information, see https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.",
+      "oneOf": [{ "type": "object" }, { "$ref": "#/definitions/expressionSyntax" }],
+      "patternProperties": {
+        "^(in|ex)clude$": {
+          "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#example-including-configurations-in-a-matrix-build",
+          "oneOf": [
+            { "$ref": "#/definitions/expressionSyntax" },
+            {
+              "type": "array",
+              "items": { "type": "object", "additionalProperties": { "$ref": "#/definitions/configuration" } },
+              "minItems": 1
+            }
+          ]
+        }
+      },
+      "additionalProperties": {
+        "oneOf": [
+          { "type": "array", "items": { "$ref": "#/definitions/configuration" }, "minItems": 1 },
+          { "$ref": "#/definitions/expressionSyntax" }
+        ]
+      },
+      "minProperties": 1
+    },
     "reusableWorkflowCallJob": {
       "$comment": "https://docs.github.com/en/actions/learn-github-actions/reusing-workflows#calling-a-reusable-workflow",
       "description": "Each job must have an id to associate with the job. The key job_id is a string and its value is a map of the job's configuration data. You must replace <job_id> with a string that is unique to the jobs object. The <job_id> must start with a letter or _ and contain only alphanumeric characters, -, or _.",
@@ -298,26 +323,7 @@
           "description": "A strategy creates a build matrix for your jobs. You can define different variations of an environment to run each job in.",
           "type": "object",
           "properties": {
-            "matrix": {
-              "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix",
-              "description": "A build matrix is a set of different configurations of the virtual environment. For example you might run a job against more than one supported version of a language, operating system, or tool. Each configuration is a copy of the job that runs and reports a status.\nYou can specify a matrix by supplying an array for the configuration options. For example, if the GitHub virtual environment supports Node.js versions 6, 8, and 10 you could specify an array of those versions in the matrix.\nWhen you define a matrix of operating systems, you must set the required runs-on keyword to the operating system of the current job, rather than hard-coding the operating system name. To access the operating system name, you can use the matrix.os context parameter to set runs-on. For more information, see https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.",
-              "oneOf": [{ "type": "object" }, { "$ref": "#/definitions/expressionSyntax" }],
-              "patternProperties": {
-                "^(in|ex)clude$": {
-                  "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#example-including-configurations-in-a-matrix-build",
-                  "type": "array",
-                  "items": { "type": "object", "additionalProperties": { "$ref": "#/definitions/configuration" } },
-                  "minItems": 1
-                }
-              },
-              "additionalProperties": {
-                "oneOf": [
-                  { "type": "array", "items": { "$ref": "#/definitions/configuration" }, "minItems": 1 },
-                  { "$ref": "#/definitions/expressionSyntax" }
-                ]
-              },
-              "minProperties": 1
-            },
+            "matrix": { "$ref": "#/definitions/matrix" },
             "fail-fast": {
               "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast",
               "description": "When set to true, GitHub cancels all in-progress jobs if any matrix job fails. Default: true",
@@ -561,26 +567,7 @@
           "description": "A strategy creates a build matrix for your jobs. You can define different variations of an environment to run each job in.",
           "type": "object",
           "properties": {
-            "matrix": {
-              "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix",
-              "description": "A build matrix is a set of different configurations of the virtual environment. For example you might run a job against more than one supported version of a language, operating system, or tool. Each configuration is a copy of the job that runs and reports a status.\nYou can specify a matrix by supplying an array for the configuration options. For example, if the GitHub virtual environment supports Node.js versions 6, 8, and 10 you could specify an array of those versions in the matrix.\nWhen you define a matrix of operating systems, you must set the required runs-on keyword to the operating system of the current job, rather than hard-coding the operating system name. To access the operating system name, you can use the matrix.os context parameter to set runs-on. For more information, see https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.",
-              "oneOf": [{ "type": "object" }, { "$ref": "#/definitions/expressionSyntax" }],
-              "patternProperties": {
-                "^(in|ex)clude$": {
-                  "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#example-including-configurations-in-a-matrix-build",
-                  "type": "array",
-                  "items": { "type": "object", "additionalProperties": { "$ref": "#/definitions/configuration" } },
-                  "minItems": 1
-                }
-              },
-              "additionalProperties": {
-                "oneOf": [
-                  { "type": "array", "items": { "$ref": "#/definitions/configuration" }, "minItems": 1 },
-                  { "$ref": "#/definitions/expressionSyntax" }
-                ]
-              },
-              "minProperties": 1
-            },
+            "matrix": { "$ref": "#/definitions/matrix" },
             "fail-fast": {
               "$comment": "https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast",
               "description": "When set to true, GitHub cancels all in-progress jobs if any matrix job fails. Default: true",

diff --git a/action.yml b/action.yml
@@ -13,7 +13,7 @@ outputs:
     description: The rdme command result output
 runs:
   using: docker
-  image: docker://ghcr.io/readmeio/rdme:8.6.5
+  image: docker://ghcr.io/readmeio/rdme:8.6.6
   args:
     - docker-gha
     - ${{ inputs.rdme }}