RG

Commented on ReviewPhin · Jul 12, 2026

@Zain Sheikh I never tested it totally airgapped, but by default database is sqlite file, and model can be configured to point at self hosted api. As long as you can host your model, it has no reason to reach to the Internet (unless there is something in GitHub Copilot SDK/CLI that I don't know about). Just manage your expectations - unless you are able to host quite larger models on your own, results will be limited to the quality of what model can give you. There is some middle ground - run it in private network on azure (or any other cloud that gives you model hosting options) and configure it to work on models that azure hosts for you - e.g. gpt-5.6-terra on high. In such case you both have a smart model and your data stays in "your" network, just not on your machines.

Commented on ReviewPhin · Jul 10, 2026

@Zain Sheikh There is a bit of prompt composition that makes sure ReviewPhin does not focus on small things and pays more attention to higher importance findings. But in the end that depends on model you chose to use. From using it, I can tell that both GPT-5.4 and GPT-5.5 work great with that, chosing mostly the things that are more impactful. Qwen-27b has tendency to focus more on smaller things, that are less important. And yes, it works with GitLab CE edition. It does not rely on any paid features, nor on GitLab Duo - it's simple webhook + clone + api calls combination on GL platform. I am using it on self-hosted GitLab CE right now and it works perfectly.

Commented on ReviewPhin · Jul 8, 2026

@Richard Anderson Optimization at the moment is mostly me trying stuff and playing with context. At the moment it relies only on model knowledge about given language which is perfectly fine if you use smarter models like gpt-5.5. They are still efficient enough to cover team of 5-10 devs with just one GH license (although mileage will vary depending on CR size, repo size etc). There is built-in command that summarizes all run metrics and storage table to record those from past runs. I could share some numbers with you, but tbh they span so wide range, I don't think it will give you much info. Right now I was focusing mostly on efficiency, features and correctness. I didn't have to touch token optimization yet, so I am sure once I do, there will be a lot to cut out. But so far my original strategy worked well: Get what you can programmatically from code review platform, pass that info to reviewer, give it basic tools to find details in code. You are able to specify different model profiles. Each profile has two models at the moment - reviewer and chatter. Context is gathered by platform provider which is not a model at the moment, but a json that gathers MR discussions etc. Beyond that, model has access to checked out branch and has tools to read into the code as it wishes during review. Each model profile can use different models, or different model hosting altogether. That depends on how you configure it. I am thinking on exposing more roles - router to start with to better discover if review is needed (sometimes general comment response, memory or web search will be enough). When it comes to tools per language there are two paths I am planning to explore, once I find time for it: 1. Give reviewer access to CI/CD pipeline summary and allow it to read logs, statuses etc. This will help it understand the state of the branch 2. Preinstal some tools for languages or extract job queue to dedicated workers - While both may be needed, I am simply not there yet. ReviewPhin is barely couple months old and mostly growing on my spare time, so the majority of my focus went into interacting with developers - review, summarize, respond to mentions etc.

Commented on ReviewPhin · Jul 8, 2026

@Zain Sheikh At the moment GitLab (including self-hosted) and GitHub are the only supported platforms. However, the server allows you to load custom platform provider as js module as long as it conforms to provider API I prepared. That API is still a bit messy, so until I clean it up, there will probably not be many platforms added. But tbh that depends mostly on how many people are interested in other platforms. If enough people ask e.g. for BitBucket, I'll take the time to model this connection as well.

Commented on ReviewPhin · Jul 8, 2026

@Thomas Jankowski I spent a lot of time tuning the prompt fragments for that, but in the end the signal to noise ratio depends highly on the models you've used. E.g. When I used qwen-27b for reviews (we have it in our company network), the findings were rather small things and most of them were accurate. I had to then use ReviewPhin memory to fine tune what is reported in given project. But when gpt-5.4 or 5.5 are used for review, findings are 99% accurate, larger scale issues that are missed and I had to finetune only few details. E.g. it detected that sqlite index was no longer needed after storage provider got different API. Or that one of the cli options, that was required is unnecessary, because in the end I refresh given data every webhook received. I ended up using gpt-5.4 for most of reviews and trusting them to highlight important stuff. And even then, I can respond to comments that are innacurate and either tell ReviewPhin to remember some misunderstood fact for future reference, or simply tell him to resolve given finding.

Commented on Happy Changelog · May 18, 2025

Hey everyone, wanted to share some cool updates for Happy Changelog pipelines for GitHub and GitLab! I figured some of you might benefit from them. I've added the ability to use customizable templates for your changelog version titles, giving you more control over the look. There's a new option for injecting custom scripts before new changelog is committed! This will help you automate other file changes after a version is created - update README, other version files, or whatever you need. Both workflows already use this for readme updates if you need a place to copy from. Plus, I enhanced the integration with the Changelog Browser. You can now provide a custom URL for your Changelog Browser and control exactly how the links are generated, choosing between the default branch (which is now the new default!), a specific commit, or a version tag. I realize it's not that useful for SaaS GitLab where public files are CORS-ed, but I'll work on that as well on Changelog Browser Side at some point.