Skip to content

CITGM style ci for direct express deps #304

Open

Description

@jonchurch

Have we discussed this before, officially?

CI job in direct dep repos we own which run express tests against changes to the package.

(CITGM - Canary In The Gold Mine)

Proposal

In direct express dependencies, run a CI job on PR and push to pull down express, npm link/install the local package, run tests.

Benefits

  • Early detection of breaking changes
  • Reduce the manual labor of checking if a package change impacts express functionality
  • Could automatically alert the TC to especially impactful changes we should pay attention to

more words

Not as a blocker on merge of course, but as a quick heads up to signal if a change would break something in express. For both the submitter and the reviewer.

This style of CI is new to me. Its unclear how/if we "get back to green". Specifically, ci that is always red isnt useful. We can code for that though in the ci or alert system, notifying humans on newly failed tests. First pass would just be running express tests and exit 0 or 1

It would of course likely fail when working on a package major not being used by the express version being tested against.


This thought is inspired by discussions in tc chat about greater maintainer autonomy and change awareness in the individual packages.

Independent of that topic, I see value in CITGM style tests.

Activity

  1. jonchurch commented on Nov 13, 2024

    @jonchurch
    MemberAuthor

    havent tested this yet

    name: Express Dependency Monitor (EDM)
    
    on:
      push:
        branches: [ main ]
      pull_request:
        branches: [ main ]
    
    jobs:
      test-express-with-local-package:
        runs-on: ubuntu-latest
        continue-on-error: true  # Allows the workflow to continue even if this job fails
    
        steps:
        - name: Checkout code
          uses: actions/checkout@v3
    
        - name: Set up Node.js
          uses: actions/setup-node@v3
          with:
            node-version: '18'
    
        - name: Install dependencies
          run: npm install
    
        - name: Build package
          run: npm run build --if-present
    
        - name: Pack local package
          run: npm pack
          shell: bash
    
        - name: Store package file name
          id: packfile
          run: |
            package_name=$(jq -r .name package.json | sed 's/@//; s/\//-/')
            package_version=$(jq -r .version package.json)
            echo "packfile_name=${package_name}-${package_version}.tgz" >> $GITHUB_OUTPUT
          shell: bash
    
        - name: Clone Express.js
          run: git clone --depth 1 https://github.com/expressjs/express.git
    
        - name: Install Express.js dependencies
          run: |
            cd express
            npm install
    
        - name: Install local package into Express.js
          run: |
            cd express
            npm install ../${{ steps.packfile.outputs.packfile_name }}
    
        - name: Run Express.js tests
          run: |
            cd express
            npm test
    
    
  2. ljharb commented on Nov 13, 2024

    @ljharb
    Contributor
  3. UlisesGascon commented on Nov 14, 2024

    @UlisesGascon
    Member

    I love this idea a lot!

    CITGM is currently a challenge when we do releases in Node. This will helps us to anticipate issues ahead of releases ❤️.

    Aside of targeting commits from our side on > push. I will suggest to trigger this workflow based on cron jobs so we can test this against the last canary release available, etc... Otherwise our anticipation will be very limited.

    Obviously we can add some notifications (issues) in case that the actual tests fails and not due binaries availability.

    cc:@marco-ippolito and @RafaelGSS for sure they can add much more context and ideas here 👍

  4. added
    top priorityIssues which the TC deem our current highest priorities for the project
    on Jan 28, 2025
  5. bjohansebas commented on Mar 3, 2025

    @bjohansebas
    Member

    How WIBY works right now, I don't think it's ideal for Express, since we would have to create a GitHub token between the repositories with write permissions. I am working to make this unnecessary, which is something I will be working on these months (see pkgjs/wiby#154).

    Here's an example of how it works right now (bjohansebas/body-parser#1, bjohansebas/express#1).

  6. removed
    top priorityIssues which the TC deem our current highest priorities for the project
    on Jul 2, 2025
  7. bjohansebas commented on Jul 3, 2025

    @bjohansebas
    Member

    In about two weeks I'm going on vacation, so I'll be able to dedicate some time to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions