S
Silk.NET10mo ago
Perksey

Plans for CI

Plans for CI Versioning Number: X.Y.Z CI will automatically handle versioning, committing it directly to the main branch as part of the automated release pipeline ("Tuesday Snap"). For Patch Tuesday, it sets Z to zero and increments Y; X remains unchanged. For emergency patches, only Z is incremented, leaving the others untouched. The version is automatically incremented, pushed to main by CI, and then tagged and released. Patch Notes Patch notes will be auto-generated, with PRs checked against a standard format. PR titles should start with one of these words (in this order): - Stabilised - Added - Updated - Improved - Fixed - Removed - Discontinued - Miscellaneous PR titles can be prefixed with (EXPERIMENTAL!) to exclude support obligations, or (Internal) or (Tidy) to bypass checks and not be included in the notes. This acts as a PR check and will fail if not met. Develop vs Main Develop is the development branch, with nothing committed directly to main except for merges and bindings regeneration. On the first Tuesday of each month, CI opens a "develop PR" to merge develop into main (so we don't forget). We can reject this PR but we must remember to open one later. Old CI branches (without an associated open PR) are removed every Monday. Each main branch commit is automatically merged onto develop, raising an issue if not possible. Fast Track All PRs must target develop, but with Silk.NET team approval, a PR can be targeted at main and labelled "fast-track." This requires majority maintainer approval, only for extenuating circumstances. Emergency Patches PRs targeting main can be marked with the "emergency-patch" label. Upon majority approval, an emergency patch PR is merged and tagged. Bindings Regeneration CI regenerates bindings every Thursday, opening a PR for each. It updates submodules to the latest tags unless configured differently. If regenerated bindings appear faulty, a maintainer can manually handle it by closing the PR.
8 Replies
Perksey
Perksey10mo ago
. @Maintainer PTAL clarification on fast-track: this is basically if we have something cooking on develop and want to squeeze a fix in before the tuesday snap https://discord.com/channels/521092042781229087/587346162802229298/1158298803204526110 @kaijellinghaus wdym reinvent the wheel? It’s just a PR check? And the commit conventions is literally just so that the release notes look good when generating them.
Kai
Kai10mo ago
most of this is done by conventional commits already, no?
Perksey
Perksey10mo ago
Yes but following a different convention we could use conventional commits but there’s then a chance that the release notes do not make grammatical sense and that’s just the commit thing, conventional commits won’t do the branch management for us
Kai
Kai10mo ago
fair I suppose
Perksey
Perksey10mo ago
anyways that really wasn't the bit i was hoping you'd focus on haha are you happy with all the other stuff?
Kai
Kai10mo ago
oh I thought we had discussed that ahead of time - I'm happy with the change in general, as long as the automation somewhat works IMO this is more work in general, but if it's automated I think it makes a lot of sense which is why I brought up that there's at least adjacent existing tools, so maybe we don't need to produce as much other code
Perksey
Perksey10mo ago
yeah that’s the goal, I basically want is to always be shipping updates with at the very least regenerated bindings the binding automation works today but keeps falling over when the branch isn’t deleted
Lyris the Kitori
Lyris the Kitori10mo ago
i dont have any problems with this