Skip to content

Add CS2Tracker Extension #213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MuhammedResulBilkil wants to merge 2 commits into
base: main
Choose a base branch
from
+4 −0
Open

Add CS2Tracker Extension #213

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4eed28d
Add cs2tracker-extension
Jul 25, 2026
ea08246
chore: bump cs2tracker-extension to v1.0.1
MuhammedResulBilkil Jul 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .gitmodules
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,3 +73,6 @@
[submodule "plugins/gratitude"]
path = plugins/gratitude
url = https://github.com/BlythT/Gratitude-Millennium-Plugin
[submodule "plugins/cs2tracker-extension"]
path = plugins/cs2tracker-extension
url = https://github.com/MuhammedResulBilkil/cs2tracker-extension
Comment on lines +76 to +78

@MuhammedResulBilkil MuhammedResulBilkil Jul 30, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, and I'd rather answer it than leave it sitting.

The principle is right: master is a mutable ref, so the images the store renders after a merge aren't necessarily the images anyone reviewed. Pinning would fix that, and I've checked that it's a clean swap — all the referenced assets already resolve at the v1.0.0 tag, so it's a two-line change to plugin.json and a submodule bump here, nothing has to move.

What makes it awkward rather than automatic is the release pipeline. Releases here are cut by semantic-release, which decides the version number at release time and writes it into plugin.json itself. So a URL naming v1.0.1 has to be committed before the tooling has decided the release is v1.0.1, which means hand-holding a value the pipeline otherwise owns, on every release, forever, or the images silently keep pointing at the previous tag.

So: I'd rather do this properly at the next release, where I can wire the asset URLs into the same substitution semantic-release already performs on the version field, than bolt a hardcoded tag on now and quietly create a step that gets forgotten. If a maintainer would prefer it pinned before merge, say so and I'll cut a 1.0.1 for it — I just don't think a bot-flagged nit is worth a release on its own, and I'd rather ask than assume.

Worth noting for whoever picks this up: no other plugin currently in the database sets thumbnail or splash_image at all, so there's no house convention here either way. If the project does want pinned asset refs as a rule, that's a template or docs change rather than something to settle in one submission's thread, and I'm happy to be the first to follow it.

@MuhammedResulBilkil MuhammedResulBilkil Jul 30, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done — this is fixed rather than deferred. Thanks for the flag; it was a fair one.

The submodule now points at f5e67bf (v1.0.1), whose plugin.json reads:

"thumbnail":    ".../cs2tracker-extension/v1.0.1/assets/thumbnail.png",
"splash_image": ".../cs2tracker-extension/v1.0.1/assets/splash.png"

I said earlier I'd rather not hardcode a tag, because that fights semantic-release — it owns the version field — and adds a release step to forget. That objection turned out to be answerable rather than blocking: the rewrite now happens inside the prepare step that already syncs the version, so the tag in these URLs is derived from the release being cut, not typed by hand. @semantic-release/git commits plugin.json during prepare and semantic-release tags that commit, so the tag the URLs name is the tag they're committed under, and assets/ exists there. The apparent chicken-and-egg isn't one. Every future release re-pins itself.

The --check mode CI already runs gained the matching assertion, so a hand-edit back onto a branch ref now fails the build:

sync-version: plugin.json "thumbnail" is pinned to "master", not "v1.0.0"

$schema is deliberately left on Millennium's main so editor hints track the schema as it changes; the test suite asserts that exclusion so the rule can't later be widened to "every raw URL" and freeze it by accident.

v1.0.1 contains no functional change — it exists only to carry this. Both pinned URLs return 200 at the tag.

One note for whoever reviews, unchanged from before: no other plugin in the database sets thumbnail or splash_image at all, so there's still no house convention here. If the project wants pinned asset refs as a rule, that's a template or docs change rather than something to settle per-submission — happy to have been the first to follow it either way.

1 change: 1 addition & 0 deletions plugins/cs2tracker-extension
Open in desktop
Submodule cs2tracker-extension added at 9be073