Issues with check_dependency_updates

[andrewtavis]

Terms

• I have searched all open bug reports
• I agree to follow activist's Code of Conduct

Behavior

In #724 we developed check_dependency_updates, but this workflow has proven to not work particularly well as seen in #1089 and #1011. Issues are:

• The data for the issue title isn't formatted
• The updates that would happen aren't added to the issue text
  • We'd like the full error text
• The frontend errors seem to not be being included

Ideally we'd have this workflow running every two months and we'd then get a report that would tell us which dependencies would cause new errors so that we can react to these changes.

From the original issue #724:

• We'll keep the current Dependabot warnings and react to them as needed
• We'll run a workflow every two months
• This workflow will update all dependencies to the next available minor release
• The backend and frontend checks will be ran such that new errors will be detected
• Results will be logged and new issues will be made to work on them
• This two month process will coincide with Code Night 🌙 such that we can work together to squash 'em all 🐞

Would be great if someone wanted to look into this! 😊

[Abhi-Bohora]

👋 @andrewtavis I am currently looking into this, can you please assign this to me ?

[andrewtavis]

Would be great to get your help here, @Abhi-Bohora! Thanks for taking this on :)

[Abhi-Bohora]

our current check_dependency_updates.yaml creates two error_log.txt files one on the frontenddir and one on the root dir.

the issue we are seeing here #1011 comes from error_log.txt file which is on the root. It seems like error_log.txt which is on the frontend dir seems to be ignored, but in there also there is not much information just this only

Type check failed.
ESLint check failed.

My question is wouldn't it be better if the workflow creates one markdown file let's say reports.md file instead of two .txt file. and let GitHub action create the issue using content of the reports.md. reports.md will look something like this this is the actual result of check_dependency_updates.yaml that i am working on please let me know what information it is missing or should include as this will be used while creating the issue by github action.

if you have any suggestion idea please let me know 😊

btw i am using https://github.com/nektos/act and docker to run the github action locally

Thanks 🚀

[andrewtavis]

I'll need to look through reports.md more, but I totally support the implementation here :) It's hard to figure out the errors for TypeScript from the JSON, so maybe that could be parsed a bit?

[Abhi-Bohora]

adding this one here so it wouldn't be one long message😅
these file will be changed by running the workflow

since i think we are only creating the issue using actions not pr are we thinking of updating dependency ourself by looking at the issue or are we letting action to create the pr too with the changed files? please let me know because the workflow will change the dependency in the package.json to the next available version as mention in the issue.

[andrewtavis]

Having a clear package_name old_version -> new_version for both the frontend and backend without separate sections might also be nice? Open to your suggestions on this though :)

[Abhi-Bohora]

@andrewtavis yeah that will be good. in a single file markdown file ? please let me know considering the above comments 😊

[andrewtavis]

Single markdown file is fine :) The decision between the issue and the PR is an interesting one. I wouldn't want the old files in the PR, and the pressure of that way of doing it would really fall on the maintainers, whereas if we did an issue we could also create sub issues for community members to do an update and complete all the fixes. We could also automatically mark the issue as a good first issue and help wanted, with an explanation at the top that the community would be welcome to help us with it. How does this sound? :)

[Abhi-Bohora]

@andrewtavis yeah that sound good. if i understand this correctly, We let the action create a nice issue with what dependency update is available and list all the dependency with old version as well as next available version, as well as errors etc. and let the community raise a pr by upgrading/fixing those by referring to the issue ?

[andrewtavis]

Exactly that, yes :) Let me know if you have further questions, and looking forward to getting this fixed! 😊

[andrewtavis]

Closed by #1131 🚀 Wonderful work, @Abhi-Bohora! Really appreciate the care you put into this :) :)

[andrewtavis]

If you have suggestions for #1125 and my comment here that the coverage report isn't ignoring files that it should, then this would maybe be a simple next step to help out with :) Aside from this, please let us know what other issues you'd have interest in looking into!

[Abhi-Bohora]

@andrewtavis i will look into it and let u know...✅