Recurring Merge Conflicts in plugins.txt Between Release and Main Branches

[ahmed-arb]

Problem

Every time changes are merged from the release branch to main in the GitLab pipeline, merge conflicts occur in plugins.txt because:

• Release branch: Installs plugins from PyPI with version constraints (e.g., tutor-android>=20.0.0,<21.0.0)
• Main branch: Installs plugins directly from their GitHub main branches (e.g., https://github.com/overhangio/tutor-android@main)

This structural difference causes predictable conflicts on every release merge, requiring manual intervention to resolve.

Proposed Solution

Handle plugin installation similarly to how we handle OPENEDX_COMMON_VERSION between main and release branches. Use the __version_suffix__ to determine which plugins configuration to use.

Implementation Strategy

Modify .hatch_build.py to conditionally load plugins based on __version_suffix__:

• If __version_suffix__ is "main" → load plugins from a separate config file (e.g., plugins-main.txt) that uses GitHub URLs
• Otherwise → load plugins from plugins.txt with PyPI version constraints

This way:

• Both branches can have the plugin lists in their respective config files
• No merge conflicts occur since each branch uses its own config file
• The logic to determine which file to use lives in .hatch_build.py

Impact

Eliminates recurring manual merge conflict resolution in the GitLab CI/CD pipeline, reducing maintenance overhead and preventing potential deployment delays.

References

• Documentation: GitLab and Release Pipeline