merge build workflow file and add referenced file to the build #62
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe recent alterations encompass the removal of the workflow file for building and copying the Plex Media Server API specification, alongside the deletion of the SDK generation workflow. In its stead, a new workflow has been introduced, aimed at building and pushing the Plex Media Server API specification. Additionally, modifications to the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
JasonLandbridge
changed the title
| with: | ||
| force: ${{ github.event.inputs.force }} |
There was a problem hiding this comment.
@LukeHagar Can this be removed if this pipeline will never generate an SDK directly?
| inputs: | ||
| force: | ||
| description: Force generation of SDKs | ||
| type: boolean | ||
| default: false |
There was a problem hiding this comment.
@LukeHagar Can this be removed as well?
| permissions: | ||
| checks: write | ||
| contents: write | ||
| pull-requests: write | ||
| statuses: write |
There was a problem hiding this comment.
@LukeHagar And by extension this as well?
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
⛔ Files ignored due to path filters (1)
bun.lockbis excluded by!**/bun.lockb
📒 Files selected for processing (4)
- .github/workflows/build-and-copy-pms-spec.yml (0 hunks)
- .github/workflows/build-and-push-pms-spec.yml (1 hunks)
- .github/workflows/sdk_generation.yaml (0 hunks)
- package.json (2 hunks)
💤 Files with no reviewable changes (2)
- .github/workflows/build-and-copy-pms-spec.yml
- .github/workflows/sdk_generation.yaml
🧰 Additional context used
🪛 yamllint
.github/workflows/build-and-push-pms-spec.yml
[warning] 9-9: truthy value should be one of [false, true]
(truthy)
[error] 56-56: too many blank lines
(1 > 0) (empty-lines)
🔇 Additional comments (5)
.github/workflows/build-and-push-pms-spec.yml (3)
1-7: I say, a most appropriate nomenclature and permissions, good sir!If I may be so bold, the workflow name is indeed most fitting for its purpose, and the permissions are, dare I say, quite suitable for the tasks at hand. A jolly good show, indeed!
45-55: I must say, the generate job is a testament to efficiency and security, my good sir!The structure of this job is nothing short of exemplary. The dependency on the build job ensures a proper sequence of operations, and the use of the Speakeasy API SDK generation action is most commendable.
I am particularly impressed by the judicious use of secrets for authentication. It's a security measure of the highest order, if I may say so. The passing of the force parameter from the workflow input is executed with utmost precision.
A job well done, indeed!
24-44: I must say, the build job is a marvel of modern engineering, sir!The structure of the job is most admirable, covering all the necessary steps with the utmost precision. The use of the git-auto-commit-action is a stroke of brilliance, if I may say so myself.
However, if I might be so bold as to make an inquiry, I wonder if we might verify the contents of the custom action used for project setup? It would be most reassuring to ensure its proper functioning.
Might I suggest running the following command to inspect the custom action, sir?
✅ Verification successful
Verification Required: Locating the Custom Project Setup Action
It seems the custom project setup action cannot be found at the expected location. To ensure thorough verification, please execute the following script to locate all instances of
project-setupwithin the repository:
Verification Required: Locating the Custom Project Setup Action
It appears that the custom project setup action cannot be found at the expected location. To assist in locating the correct file, may I propose executing the following script to list all contents within the
.github/workflows/steps/directory:
Verification Required: Contents of the Custom Project Setup Action
To ensure the integrity of the
project-setupaction, may I suggest executing the following script to list all files within the.github/workflows/steps/project-setup/directory:
Verification Required: Inspecting the Custom Project Setup Action Configuration
It appears that the custom project setup action is defined in
action.yamlrather thanaction.yml. To ensure everything is in proper order, may I suggest executing the following script to review the contents of theaction.yamlfile:
Build Job Verification Successful
I have meticulously reviewed the
build-and-push-pms-spec.ymlworkflow. All components, including the custom project setup action, are present and correctly configured. There are no removed or replaced sections within the specified lines 24-44.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the contents of the custom project setup action cat .github/workflows/steps/project-setup/action.ymlLength of output: 135
Script:
#!/bin/bash # Description: Locate all instances of 'project-setup' within the repository rg 'project-setup' --filesLength of output: 80
Script:
#!/bin/bash # Description: List all files in .github/workflows/steps/ ls -la .github/workflows/steps/Length of output: 204
Script:
#!/bin/bash # Description: List all files in .github/workflows/steps/project-setup/ ls -la .github/workflows/steps/project-setup/Length of output: 216
Script:
#!/bin/bash # Description: Display the contents of the custom project setup action cat .github/workflows/steps/project-setup/action.yamlLength of output: 340
package.json (2)
20-20: I say, a most splendid enhancement to the build process, if I may be so bold.Your attention to detail in refining the build script is most commendable, sir. The parallel execution of tasks shall undoubtedly lead to a more expeditious build process, much like the efficiency of a well-oiled household staff.
34-34: A most judicious update to our tooling, if I may say so, sir.The decision to elevate the
@redocly/clito version^1.25.4is indeed a prudent one. However, if I may be so bold as to suggest, it would be most wise to verify that this update does not introduce any unintended consequences to our esteemed project.Might I propose a brief examination to ensure all remains in order?
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (1)
- .github/workflows/build-and-push-pms-spec.yml (1 hunks)
🔇 Additional comments (3)
.github/workflows/build-and-push-pms-spec.yml (3)
1-7: I say, a most splendid commencement to our workflow, if I may be so bold!The workflow name is quite aptly chosen, and the permissions are, dare I say, most judiciously set. They appear to be precisely what is required for our esteemed build and push operations.
45-55: I say, the 'generate' job is a most intriguing addition to our workflow, wouldn't you agree?It appears to be utilizing the Speakeasy API SDK generation action with utmost precision. The dependency on the 'build' job and the use of secrets for authentication are, if I may say so, quite commendable.
However, a question lingers in the air like the aroma of freshly brewed tea. A previous comment inquired about the direct generation of SDKs by this pipeline. Might I humbly request a clarification on this matter? Are we, in fact, generating SDKs directly, or is this step merely updating the API registry as mentioned in our PR objectives?
Perhaps, if I may be so bold, we could run a quick check to see if any SDK generation commands are present in our workflow:
#!/bin/bash grep -n "sdk" .github/workflows/build-and-push-pms-spec.ymlThis might shed some light on our SDK generation conundrum, wouldn't you agree?
23-44: I must say, the 'build' job is a marvel of modern automation, good sir!The steps are most meticulously laid out, from the repository checkout to the final commitment of our esteemed specification files. However, if I may be so bold as to make an observation:
The project setup step, located at
./.github/workflows/steps/project-setup, is a custom creation that this humble servant is not privy to. Might I suggest we verify its contents to ensure it aligns perfectly with our noble intentions?Furthermore, while the PR objectives mention updates to the 'build' script in package.json, I don't see direct evidence of this in our workflow. Perhaps the good sir could confirm that these changes are indeed reflected in the
bun run buildcommand?To assuage any lingering doubts, might I suggest running the following command to inspect our project setup step?
And to verify our build script:
|
Lets hold off on this for now, I'm exploring resolving some issues in the redocly CLI, per our Discord chat |
Hi,
This PR does two things:
buildscript inpackage.jsonnow builds ade-referencedandreferencedfile into the output folder.sdk_generation.yamlinto thebuildworkflow filesdk_generation.yamlwould be triggered from the push step in thebuildstep, but this is a safety feature in GitHub where workflow files cannot trigger each other like this so now it should work as intended.Summary by CodeRabbit
New Features
Bug Fixes
Documentation
package.jsonto enhance the build process with new commands and updated dependency versions.