Architecture

Design Choice: Project stats automation commits will appear out of sync

Every few hours as based on this configuration, a GitHub Action executes some automation to rebuild the stats content of this site for each project in the src/data/projects directory.

That automation does a few things:

1. Retrieve the latest stats from GitHub for each newrelic and newrelic-experimental project registered in the projects directory using the GitHub v3 and v4 API's
2. Write that data to the staging/develop branch
3. Selectively write the develop commit to the production/main branch
4. Kick off builds to both the staging and production environments without revisioning the sites

This was chosen so that functional changes in the develop branch could be tested, reviewed, and merged intentionally while automated content updates would be kept up-to-date in both branches.

The consequence of this choice is that the commit to the develop branch is not the same identifier as the commit to the main branch for precisely the same change. In the case of a PR, from staging to production, the commit histories will appear (in those areas) out of sync, without generating a merge conflict.

Two commits for the same change isn't optimal, but it's the choice the original maintainers made. Feel free to criticize (and suggest a better solution) in an issue.