This does look useful, and is a nice idea (getting accessbile files like PDF by just committing) ... however:

1. A commit will appear after each and every push that changes the relevant files - this will necessitate force-pushing to maintain a clean history.
2. These files won't be final or reviewed by anyone (and people may well grab and build from them if gerbers are included) - we've already seen people building revC2, which isn't final yet.

I'd strongly prefer to avoid scripts making commits to an active / development branch... two alternative options:

1. Upload the files to some webhost, possibly even gh-pages, with a per-branch structure (can we clean up on branch delete?)
2. Using a "partner" branch instead might be more acceptable than sitting on top of the original branch, though it's still not great... for example:
   • user pushes to wip-revC2
   • the CI scripts produce files
   • scripts make a new branch (e.g: wip-revC2-ci or similar) that is made afresh from the top of wip-revC2 every time
     • no history, no merging
     • you'll need to be careful of existing branches that may match this name, but aren't related to the script's job
   • scripts commit & push

I don't like the filters you've got in place (e.g: filter.bom_csv.clean), and think they should all be removed. They remove the date / timestamps on commit, and reinsert "now" on checkout, which I think is 100% flawed - is there a particular reason you did this? (genuine question). Timestamps are critical information when reviewing files like this.

There are a couple of other issues (e.g: wrong title and links in README.md), but they're less problematic by themselves.

Thanks @attie, you've articulated my concerns also.