CI automation to help upgrading docusaurus-theme-openapi

[chris48s]

📋 Description

There are two React components from docusaurus-theme-openapi which we have swizzled to customise them for our needs.

This means that when we upgrade the docusaurus-theme-openapi, if either of the components we have customised (Curl and Response) have changed in the upstream package, we need to review our custom components to see if any changes or updates are needed.

I want to write a GitHub action that can flag dependabot PRs bumping docusaurus-theme-openapi that require manual intervention to review or update these components. Something like close-bot is probably a reasonable starting point for what this should look like.

[calebcartwright]

I want to write a GitHub action that can flag dependabot PRs bumping docusaurus-theme-openapi that require manual intervention to review or update these components. Something like close-bot is probably a reasonable starting point for what this should look like.

Is this proposed (I presume first step) flagging in the sense of essentially just posting some "hey Shields maintainer, pay close attention to this one" comment on the dependabot PR?

[chris48s]

I think the easiest thing (so probably the first step) is to just do something like (as you say)

if packageName == 'docusaurus-theme-openapi' then post a comment on the PR saying "hey Shields maintainer, pay close attention to this one"

But I think we could look at more elaborate stuff. One option would be to post a diff of the files from the package against the ones from our repo, or diff the specific files in the old/new package versions and say if they have changed or not.

[jNullj]

Could give a hand with this implanting, assign me if you want.

[chris48s]

If you wanted to pick this one up, that would be awesome. I think for a first implementation, just adding a warning to the PR saying:

• This package contains components we've overridden
• We need to watch out for changes to the Curl and Response components

is a great start.

https://github.com/badges/shields/tree/master/.github/actions/close-bot is probably a good point of reference for a similar-ish action we have written.

[jNullj]

So here is what i came up with (The old and new are mixed due to the way i am testing, it should not be an issue)

It will inform which components are changed, the list on the last row is dynamic, the script tests what files are changed in the diff of the tags for the two versions.

The only issue i am still testing is... I used github api to get the patch but i did not notice that patch is not a required field for the response from the api and sometimes its missing, i added a fix but now i can't replicate a case where patch field is missing, i hope i will be able to replicate this and open a PR soon.

[calebcartwright]

Awesome, that looks like some great progress there @jNullj!

[jNullj]

I changed this, it appears to be way more robust to just use the two package-lock.json files to extract the version. It is also way more robust, as some packages might update a minor version of this package sneakily.

I will PR soon, I am trying to find where this fails.

I made it so far so this warring will show even if no override was done to changed components, should i change it to hide the message if non of the components we look for did not change? or should i keep it with an empty list?

[chris48s]

This looks great based on the screenshots 😄 I think it is probably easier to follow up on the questions in the context of reviewing the PR now that you have opened that. I'll have a look over the weekend. Thanks

[chris48s]

done in #9467