Repository navigation
ci(meetings): keep the meeting archive current from the playlist - #55
Timur Tukaev (tym83) wants to merge 3 commits into
Conversation
The archive only stayed accurate while someone remembered to append a row after each meeting, and it had already fallen a meeting behind. A weekly job now reads the playlist feed and opens a pull request with any recording that is not listed yet, leaving the Topics column for a human to fill in. Signed-off-by: tym83 <6355522@gmail.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bring the archive automation up to date with main so it is reviewed and tested against the current archive, which has meanwhile fallen further behind the playlist. Assisted-by: LLM Signed-off-by: tym83 <6355522@gmail.com>
…est Thursday Recordings are published anywhere from the same day to more than a week after the meeting. Snapping the publication date to the nearest Thursday therefore pushed most recent recordings onto the following week: against the current playlist it would have dated the 20 Aug, 3 Sep and 17 Sep meetings as 27 Aug, 10 Sep and 24 Sep, without flagging any of them. The meeting date is in the video title or description, with day and month in either order. Accept a reading only when it is a Thursday within two weeks before publication, which for a fortnightly meeting leaves a single candidate. Without one, fall back to the latest fortnightly slot after the newest listed meeting that is not after the publication date, and flag the row for review. The playlist feed also has spells of answering 404, so retry with backoff before failing the run. Assisted-by: LLM Signed-off-by: tym83 <6355522@gmail.com>
Aleksei Sviridkin (lexfrei)
left a comment
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
Timur Tukaev (@tym83) NOT LGTM. Each weekly run rebuilds the branch from main and force-pushes it, which throws away the Topics a reviewer has already filled in on the open PR.
Business context: the meeting archive falls behind whenever nobody remembers to add a row, and this adds a weekly job that opens a PR for new recordings.
-
The PR body the job writes asks people to "fill it in from the meeting notes before merging". The natural place to do that is the
update-meeting-archivebranch. The next Friday run checks outmain(line 25), where the new rows are not merged yet, so the script adds them again with empty Topics. Thengit branch -D, a fresh commit andgit push --force(line 54) replace the branch, and the reviewer's edits are gone. That happens every week until someone merges. One fix: when the PR is already open, check out that branch instead ofmain, so the script sees the rows as known and exits with "no new recordings". -
When the meeting date cannot be read from the text, the fallback can land on the newest listed date, and then the row is skipped silently at
update-meeting-archive.py:135. For example, a recording without a date, published less than 14 days after the newest listed meeting, givesslots == 0, sodate == newest_listed, socontinue, with no output and no flag. The new README sentence says rows "are added automatically once it appears in the playlist", so this case should at least land in the "worth a look" list.
I ran the script on a trial merge with current main against the live feed. It adds 2026-08-20, 09-03, 09-17 and 10-01 with dates read from the descriptions, none flagged, and recomputes the counts line correctly. Repo workflow permissions allow GITHUB_TOKEN to open PRs, so the last step will work.
Non-blocking: 8aaf1f5 has no Assisted-by: LLM while the other two commits do.
| git branch -D update-meeting-archive || true | ||
| git checkout -b update-meeting-archive | ||
| git commit --signoff -m "docs(meetings): add newly published meeting recordings" | ||
| git push --force --set-upstream origin update-meeting-archive |
There was a problem hiding this comment.
While the PR is open, main still lacks the new rows, so every weekly run regenerates them with empty Topics and force-pushes over whatever a reviewer filled in. Checking out the existing branch when the PR is open avoids it.
| if video_id in known_videos: | ||
| continue | ||
| date, uncertain = meeting_date(f"{title}\n{description}", published, newest_listed) | ||
| if date <= newest_listed: |
There was a problem hiding this comment.
With no date in the text and published - newest_listed < 14 days, the fallback returns newest_listed and the recording is dropped here with no output. I'd flag it rather than skip.
2 participants
Summary
The archive only stayed accurate while someone remembered to append a row after each meeting, and it had already fallen a meeting behind.
What
A weekly workflow reads the Atom feed of the community meetings playlist and opens a pull request with any recording that is not listed yet. The meeting date is read from the video title or description, with day and month accepted in either order, and taken only when it is a Thursday within two weeks before publication. When no such date is found, the row falls back to the latest fortnightly slot after the newest listed meeting that is not after the publication date, and is flagged for review. The feed is retried with backoff, since it intermittently answers 404. The Topics column is left empty for a human to fill in from the notes.
Only meetings newer than the newest row are considered, so history is never rewritten. A cancelled meeting, or one held without a recording, produces nothing to detect — the archive now says so, and those rows stay a manual step for whoever ran or cancelled the meeting.
Why
No API key and no secret to provision: the playlist feed is public and carries the fifteen most recent entries, which is ample for a fortnightly meeting checked weekly. Nothing reaches
mainwithout review, and the job cannot invent a topic list.Preview
Verified against the current archive: a clean run reports no new recordings, and with the newest row removed the script restores it with the correct date derived from the publication date, and recomputes the counts line.