-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate browserslist DB update #101
Comments
Hi @adamstankiewicz , we can simply use dependabot to update the browserslist. I would appreciate your thoughts on it. |
@mamankhan99 Can you go into more detail around how we might use dependabot to update the browserslist? My understanding of dependabot is that it helps upgrade dependency versions (e.g., v4.0.5 -> v4.1.0), but it wouldn't necessary be able to run a command like This isn't really so much a package upgrade, but more running the above command on a regular basis. When I wrote this issue, the general idea I was thinking was potentially to create some sort of Github Action that runs We have some prior art in terms of creating shared Github Action workflows that repositories can take advantage of, e.g.:
This way, the workflow logic is defined once, and repos can opt in to use it, similar to our other shared Github Action workflows: https://github.com/openedx/.github/tree/2675600a7a2efd1df81d1ad1e550a3a9efc0a7bb/.github/workflows In terms of running a Github Action on a recurring basis, it may be configured similar to this prior art: on:
workflow_dispatch:
schedule:
- cron: "0 14 * * *" # daily (Github Actions works with UTC) |
@adamstankiewicz sorry for the delay, I did some more research and I believe you are right dependabot works fine with npm updates but can not run a command using npx. This is a test script I created to test chron job ( I will configure it io run once a week ) other than that I want to know do we need some sort of Private Access Token as used below or not ( if yes do I need to ping the owner of every repo to get it or we use a standard ). I will appreciate suggestions if you need any thing changed or a particular format of commits. Documentation: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md
|
@mamankhan99 Apologies for the delayed response... I think we should be able to use the shared Github config setting of If that doesn't work, then we'll have to get a bit more creative :) |
Can we think of any way to unlock progress, here? I see only the account MFE merged the change. |
As discussed, all of these PRs need to be updated for create-pull-request action rather than edx's testeng-ci. This PR is pending for review, once its merged, i will update rest of PRs and they will be ready to merged |
Do you guys need any reviews from maintainer teams on this? I'm fine just letting FED-BOM make the call and merge things, but we do have a couple of the open PRs sitting on https://github.com/orgs/openedx/projects/23/views/1 and I don't know how to triage them. |
@hurtstotouchfire, right now this is pending @abdullahwaheed addressing reviews on this other PR. Once that is fixed up and merged, all the current open PRs linking to this issue will be refactored based on that outcome, and only then we'll be able to push this forward. |
Main issue: openedx/wg-frontend#101 PR: #73
Main issue: openedx/wg-frontend#101 PR: #381
Main issue: openedx/wg-frontend#101 PR: #484
@abdullahwaheed, can you confirm we are now just waiting for the downstream PRs to merge? |
Happy to chime in here :) @arbrandes Yes, the shared Github Action workflow appears to be working as expected. I recently merged in the downstream PR for the Paragon repo and it worked great! We are indeed waiting on the downstream PRs to merge as this point. Personally, I feel this change is small enough / trivial that FED-BOM could safely go ahead with merging the open PRs, unless the desire was to leave this as an opt-in choice to the owning team (though, that would slightly defeat the purpose of the intent of this work). |
@arbrandes we are waiting for owning teams to merge these PRs. If its good to go, we can merge these |
As far as I'm concerned, this is totally good to go! |
@abdullahwaheed, could it be? Are we finally done here? 😅 |
yes i think we can close it now |
We are moving towards a shared
browserslist
config (https://github.com/edx/browserslist-config) to use across our JS repositories to maintain consistency in browser support across applications while ensuring it is easy to maintain with future changes (i.e., change once, impacts all consumers).However, the
browserslist
browsers database can get stale as new usage data and browser versions come out. As such, occasionally we see warnings like:To fix this, running
npx browserslist@latest --update-db
updates thecaniuse-lite
version in package-lock.json files.This issue is to find a way to automate this update process for our repositories that rely on
browserslist
, e.g., perhaps adding a Github action to each relevant repository that runs on a cron once a week (?) to do the following:npx browserslist@latest --update-db
to update the package-lock.json file to pull in updates.PRs
This is the pre-requisite:
These need to be updated after the above one gets merged:
The text was updated successfully, but these errors were encountered: