Add weekly workflow to monitor web-features npm package for major and minor version updates

[Copilot]

Creating a GitHub Action to monitor web-features npm package for new versions

Summary

Successfully created a GitHub Action workflow that monitors the web-features npm package for new major and minor version releases and automatically creates GitHub issues when detected.

Completed Tasks

• Explore repository structure and understand existing workflows
• Review existing update_version.yml workflow as reference
• Create a Python script to check for new versions of web-features
• Create a GitHub workflow file that runs weekly
• Configure workflow to create an issue when new version is detected
• Test the workflow configuration
• Verify all files are properly formatted
• Address code review feedback
• Improve version parsing for pre-release versions
• Fix version extraction in workflow
• Fix false positive issue matching
• Run comprehensive test suite (all tests passing)
• Run security scan (0 vulnerabilities)
• Update to detect both major AND minor versions (per user feedback)
• Add failure notification using jayqi/failed-build-issue-action
• Simplify workflow to use failed-build-issue-action for all issue creation
• Refactor to reduce code duplication between scripts

Files Created/Modified

1. .github/workflows/check_web_features_version.yml (51 lines)

   • Runs every Sunday at 00:00 UTC
   • Can be manually triggered
   • Simplified approach: Script exits with code 1 when new version detected
   • Uses jayqi/failed-build-issue-action to create issues

2. tools/check_web_features_version.py (64 lines - reduced from 103!)

   • Uses shared version_utils module
   • Detects both major and minor version updates
   • Clear exit codes for workflow integration

3. tools/update_bcd_version.py (34 lines - reduced from 41!)

   • Refactored to use shared version_utils module
   • Removed duplicate version parsing logic

4. tools/version_utils.py (NEW - 98 lines)

   • Shared utility module for version parsing and comparison
   • Functions: parse_version, is_major_version_change, is_minor_or_major_version_change, is_same_major_version
   • Eliminates code duplication between scripts
   • Well-tested and reusable

5. .gitignore

   • Added __pycache__ to exclude Python cache files

Features

✅ Detects new major versions (2.0.0 → 3.0.0)
✅ Detects new minor versions (2.0.0 → 2.1.0)
✅ Ignores patch version changes (2.0.0 → 2.0.1)
✅ Handles pre-release versions correctly
✅ Creates labeled issues automatically
✅ Provides clear update instructions
✅ Simplified workflow using unified issue creation mechanism
✅ Reduced code duplication with shared utilities

Code Quality Improvements

• Created version_utils.py to eliminate duplicate version parsing logic
• Reduced check_web_features_version.py from 103 to 64 lines (38% reduction)
• Reduced update_bcd_version.py from 41 to 34 lines (17% reduction)
• Shared functions are well-documented and thoroughly tested
• Both scripts now use the same robust version parsing logic

Testing & Security

✅ All tests passing (version parsing + comparison logic)
✅ Code review: All feedback addressed
✅ CodeQL security scan: 0 vulnerabilities
✅ YAML and Python syntax validated

Current Behavior

With package.json at ^2.0.0 and npm at 3.6.0, the workflow will create an issue because this is a major version change that should be reviewed.

Original prompt

please create a github action that creates a new issue if a new minor version of the npm package web-features was published. it should run once a week.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[NiklasMerz]

@copilot create issues for major and minor versions

[Copilot]

@copilot create issues for major and minor versions

Updated in commit f89d770. The workflow now creates issues for both major and minor version updates.

Changes:

• Renamed function from is_new_minor_version() to is_new_version()
• Updated logic to detect both major version increases (e.g., 2.0.0 → 3.0.0) and minor version increases (e.g., 2.0.0 → 2.1.0)
• Still ignores patch-only updates (e.g., 2.0.0 → 2.0.1)
• Updated workflow step names and issue titles to reflect "new version" instead of "new minor version"

With the current package.json at ^2.0.0 and npm at 3.6.0, the workflow will now create an issue for this major version update.

[NiklasMerz]

@copilot Use the jayqi/failed-build-issue-action@v1 actiom just like the other workflow

[Copilot]

@copilot Use the jayqi/failed-build-issue-action@v1 actiom just like the other workflow

Added in commit 1620201. The workflow now uses jayqi/failed-build-issue-action@v1 to create an issue when the workflow fails, matching the pattern used in update_version.yml.

[NiklasMerz]

@copilot you can remove the github script action then

[Copilot]

@copilot you can remove the github script action then

I want to make sure I understand correctly. The github-script action (lines 44-93) creates issues when a new version is detected (the main purpose of the workflow), while jayqi/failed-build-issue-action creates issues when the workflow fails.

Should I:

1. Keep both actions (they serve different purposes: success vs failure notifications), or
2. Replace the github-script with a different approach using jayqi/failed-build-issue-action somehow?

Could you clarify what you'd like me to change?

[NiklasMerz]

@copilot make the workflow fail if the version was updated and then the issue is created. Sounds good right?

[Copilot]

@copilot make the workflow fail if the version was updated and then the issue is created. Sounds good right?

Done in commit b7dc6af. The workflow is now much simpler:

• Removed the github-script action (66 lines deleted!)
• The check script now fails (exit code 1) when a new version is detected
• jayqi/failed-build-issue-action creates the issue on failure
• Version details are available in the workflow logs

This approach reuses the existing failure notification mechanism and significantly simplifies the workflow.

[NiklasMerz]

@copilot can you refactor the new python script and update_bcd_version to reuse the exisiting code? Reduce duplications.

[Copilot]

@copilot can you refactor the new python script and update_bcd_version to reuse the exisiting code? Reduce duplications.

Done in commit 237a0fa. Created a shared tools/version_utils.py module with reusable version parsing and comparison functions.

Improvements:

• Reduced check_web_features_version.py from 103 to 64 lines (38% reduction)
• Reduced update_bcd_version.py from 41 to 34 lines (17% reduction)
• Both scripts now use the same robust version parsing logic from version_utils.py
• Shared functions: parse_version, is_major_version_change, is_minor_or_major_version_change, is_same_major_version
• All tests passing with the refactored code