search

openedx / wg-frontend

Open edX Frontend Working Group
4 stars 0 forks source link

Automate browserslist DB update #101

Closed adamstankiewicz closed 1 year ago

adamstankiewicz commented 2 years ago

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:

Browserslist: caniuse-lite is outdated. Please run next command npm update caniuse-lite browserslist

To fix this, running npx browserslist@latest --update-db updates the caniuse-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:

PRs

This is the pre-requisite:

These need to be updated after the above one gets merged:

mamankhan99 commented 2 years ago

Hi @adamstankiewicz , we can simply use dependabot to update the browserslist. I would appreciate your thoughts on it.

adamstankiewicz commented 2 years ago

@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 npx browserslist@latest --update-db in each repo on a regular (e.g., weekly) basis.

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 npx browserslist@latest --update-db on a recurring basis, like a cron, and auto-merges its resulting package-lock.json changes in the repo.

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)
mamankhan99 commented 2 years ago

@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

name: Update Dependencies
on:
  schedule:
    - cron:  '*/5 * * * *'
jobs:
  update-dep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '16.x'
      - name: Update dependencies
        run: |
          npm install redux@4.2.x
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v4
        with:
            token: ${{ secrets.PAT }}
            commit-message: 'chore: update browserslist'
            title: Update browserslist
            body: |
              - Dependency updates

              Auto-generated by [create-pull-request][1]

              [1]: https://github.com/peter-evans/create-pull-request
            branch: update-browserslist
adamstankiewicz commented 2 years ago

@mamankhan99 Apologies for the delayed response...

I think we should be able to use the shared Github config setting of SEMANTIC_RELEASE_GITHUB_TOKEN which should already be accessible by all repos without any extra effort (example)

If that doesn't work, then we'll have to get a bit more creative :)

arbrandes commented 1 year ago

Can we think of any way to unlock progress, here? I see only the account MFE merged the change.

abdullahwaheed commented 1 year ago

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

hurtstotouchfire commented 1 year ago

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.

arbrandes commented 1 year ago

@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.

arbrandes commented 1 year ago

@abdullahwaheed, can you confirm we are now just waiting for the downstream PRs to merge?

adamstankiewicz commented 1 year ago

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).

cc @abdullahwaheed

abdullahwaheed commented 1 year ago

@arbrandes we are waiting for owning teams to merge these PRs. If its good to go, we can merge these

arbrandes commented 1 year ago

As far as I'm concerned, this is totally good to go!

arbrandes commented 1 year ago

@abdullahwaheed, could it be? Are we finally done here? 😅

abdullahwaheed commented 1 year ago

yes i think we can close it now