MapsterMapper
[Enhancement][CI] Add Branch Protection, Code Analysis and Project board
Hello @DocSvartz, @stagep, @andrerav,
while reviewing this topic I noticed a few improvements that could help us avoid similar issues in the future. Since I don’t have access to Settings → Code and Automation → Rules → Rulesets, I can’t apply them myself, but I would like to propose the following for your consideration.
1. Branch protection for the default (master) branch
Given that we now have four people who can review pull requests, it would be beneficial to introduce a branch protection rule that:
- requires all changes to go through a pull request
- requires at least one approved reviewer before merging into master
This is a common pattern in OSS repositories to ensure code quality and prevent accidental direct commits.
2. Introducing a structured release branch strategy (for backporting)
It might also be helpful to introduce a dedicated release structure like:
releaserelease/stable/<version>
This is a common workflow in OSS projects and would allow clean backporting of fixes to already published versions, without forcing users to adopt breaking changes from ongoing development. This could be valuable for Mapster in the long term, especially regarding stability and predictable package updates.
3. Strengthening CI feedback: code scanning, nullability analysis, and explicit method contracts
In the GitHub Action (“Build and test”), I noticed analyzer annotations such as “possible null reference exception”. Since unexpected null behavior is undesirable in a published package, I would suggest enabling more comprehensive static analysis and code scanning.
Possible improvements:
- Enable GitHub Code Scanning (e.g., CodeQL) to detect nullability risks, unsafe patterns, and API-level issues
- Consider treating selected analyzer warnings as errors or failing CI on critical diagnostics
- Where applicable, use attributes such as
[NotNullIfNotNull],[NotNull],[MaybeNull], etc., to make method contracts explicitly null-aware.
This would allow us to catch potential nullability issues earlier, improve API clarity, and reduce the likelihood of runtime null-related failures for consumers of the package.
→ to implement CI for Code Scanning I would suggest to start with the template provided from GH and maybe someone of you could apply required setup steps that are Mapster specific as there is already a workflow for build & test ?
4. Introducing a GitHub Project for issue tracking and triage
To improve transparency and coordination around ongoing work, it may be beneficial to set up a GitHub Project Board This would allow us to track, categorize, and triage issues and pull requests more efficiently, while providing a clear overview of priorities, progress, and open tasks.
A project board could help:
- visualize the current state of issues and PRs
- support maintainers in triage and planning
- make contributor workflows more predictable
References you could look into:
- Project board from the ASP.NET Core Docs Team: https://github.com/orgs/dotnet/projects/312
- Project board for my own Repos: https://github.com/users/DevTKSS/projects/1 (not as pretty as theirs ;) )
It's possible to set up Workflows e.g. along labels that are added so by this we could automate the (base) management for this to not have way more work then it helps us, but we would need to check and improve the available labels then 👍
@andrerav as GitHub preserves the branch protection rules for admin role, I think you will be the one to apply this, if this suggestion would be considerable
Personally, I don't fell that I should be able to approve Mapster code PRs but that @andrerav and @DocSvartz can. However, if we determine how the documentation is to be maintained (#829 ) and changes to the documentation go through a PR, then I am comfortable to approve those PRs. I did commit to improve the documentation but did not really follow up with any contributions. So I agree with everything that @DevTKSS suggests.
@stagep For documentation PRs, I prefer having a second reviewer, especially for wording, since I’m not a native English speaker 😁.
Regarding code reviews: The initial checks — similar to our build-and-test workflow — already catch issues like the current nullability warnings in the Core namespace. In my own repos, Copilot Review runs automatically when a PR is marked ready for review. It doesn’t replace a required human review, but it provides an additional early check.
Branch protection also prevents accidental direct commits or merges — for example if someone forgets to switch branches. GitHub blocks this by default, unless a maintainer explicitly confirms bypassing the rule. This acts as a useful safeguard.
If a reviewer agrees, they approve; if not, they can send it to triage. A project board would help us track and prioritise such cases more easily.
@DevTKSS I am a native English speaker and I would not have known that English was not your first language unless you had told me this. TBH your English is better than some English speakers :)
@DocSvartz yes I help people with issues but I guess I don't think of this as contributing as in contributing to the code in the way that you do. But now that you mention this, I realize that I do contribute but in a different way than you do. And now @DevTKSS is providing some new energy, so things are looking good here in MapsterLand :)
@stagep 👍 I'm simply mentioning you in the PRs regarding configuration changes and would like to hear your opinion before accepting it`s.
@DocSvartz I'm going with @DevTKSS on the changes. They seem more knowledgeable than me when it comes to maintaining a repo in GitHub. I use Azure DevOps for work so my GitHub knowledge is way below theirs.
@stagep Ок. But I'm actually more interested in your opinion on the migration to ITypeadapterConfig to supporting mapster.fluent and this .
But in any case, this won't be in the next release.
@stagep I created a DevOps for my Repo MyManufacturerERP (which is where I am attempting to also use Mapster + Mediator for at least the CA side, not sure if I can make it work on my client side too 🤔 ), but I did not manage so far, to get even KeyVault taking action in this, which was my initial target when signing in to Azure DevOps from my small settlement domain 👀 since they changed the auth/domains its like mission impossible, while I was thinking as its the same company in general, VS 2022 which I was using then would have great support for KeyVault 😬 turns out it's not. somehow I seem to managed to break it 😅
@DevTKSS So KeyVault shows as a Connected Service but does not work. I am already on VS2026 so can't help you directly with VS2022. This is a side issue to Mapster. I am happy to troubleshoot with you, here is not the place, but I am happy to help you in any way. We just need to do this outside of this repo. Also, as this is about secrets, it adds another layer of difficulty in helping someone who is "outside" of the secrets.
@stagep I did test this last time in VS2022 but have moved to 2026 after the Dotnet Conf, so that should not be a problem 😄 But I think I got it now working 🤔 I think the problem was, that I didn't had MFA enabled and the vault might needed to be registred before trying to connect from the IDE 👍 just meant to share the fun fact as you mentioned DevOps 😄
@DevTKSS glad to hear you got it working. Little things can become quite frustrating when they don't work as intended. I always document everything that I know might break again so that when something breaks, instead of trying to figure out how to fix it again, I look in the documentation and there are the steps that I did to fix it the previous time. Doing this has saved me days of my life, and saved my sanity!