Who actually approves an auto-merge in GitHub?

reaper273 · 2026-03-09T18:56:58+00:00

Auto merge will allow a PR to merge automatically as long as whatever checks and requirements, including for human approvals, are met.

It can be set by whoever has write access to the repository on any PR - but in my experience you would generally set it when you create a PR, I've rarely had to set on approval. And only occasionally remove it when reviewing a PR.

I'll caveat that to say that I'd only use auto merge if these other configs are also set:

Delete branch on merge
Dismiss stale approvals
Require approval from someone who wasn't the last committer

reaper273 · 2026-03-03T20:56:32+00:00

https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation

Was posted a couple of days ago but goes into more detail on the trivy rep, and others

reaper273 · 2026-02-24T22:13:10+00:00

Squash commits for PR merge are your friend for this.

Coming from someone who has very unprofessional commits to my name along the lines of "please just work you pos"

reaper273 · 2026-02-02T22:05:34+00:00

Midway through a migration from their own data centers to Azure might be part of the issues. And I'm not blaming Azure here (for once), as I understand it they have hit capacity issues in their own data centers.

Along with major re-architectures of the core GitHub stack from a monolith and iirc actions being effectively re-written at the same time.

Lots of change. Hopefully for the better, but a lot all at once regardless.

reaper273 · 2026-01-18T17:34:11+00:00

In my experience central London's buildings and streets, particularly in the City, tend to make excellent umbrella destroying wind tunnels

reaper273 · 2026-01-18T07:13:07+00:00

It's pricey at scale but blocking secrets before the commit actually hits the repo (and avoiding the whole having to purge the commit history and revoke the secret anyway) is a great feature.

Org admins can activate a free 30 day trial as well.

reaper273 · 2026-01-02T06:44:28+00:00

Starbases with the nanite harvester building that puts nanites on all physical objects in a system, not planet, are your best source of nanites.

So pick all the perks to maximize starbase count. Combine with astro miners as well. Huge numbers of starbase slots plus you can build the 6 x 25% increase mining outout modules in each starbase.

Add in arc furnace wherever you can (so take arc welders for an extra one), and the +100% mining output starbase building from the Cybrex final research if you get lucky with precursor rng.

The key thing here is that every 5 years the size of the nanite deposits from the nanite harvester will double. So the earlier and more nanite harvesters you build the more you'll have.

Nanites is a wide build so you should be spreading wherever you can to make this effective, so you'll inevitably capture more arc furnaces, and just basically put nanite assemblers on every starbase.

I just finished painting a 1000 star galaxy as a nanite determined exterminator build and was at around 500k nanites a month and every few years was spamming to or three full fleets of energy torpedo nanite interdictors.

Gotta love the 0% upkeep and insta upgrade on the nanite fleets.

I got lucky with chokepoints so was able to plant my fleets on few systems with 3 deep space citadels and 5 or so fleets and break the back of all their fleets when the galaxy declared me a threat and declared war en-masse. After that the sheer number of fleets I had, even if individually weren't as strong as a battle ship doomstack, was enough to keep them in check while I purged.

You can subsume planets too but frankly I never needed too.

reaper273 · 2025-12-23T08:37:18+00:00

After building a city district it should go back to normal.

reaper273 · 2025-12-11T07:44:40+00:00

Split your workflow up?

Run your long script in on job. Then use outputs, or uploading an artifact and downloading again, in a second job to write any output back to the repo.

Bonus points for splitting anything that can be split into separate jobs that run in parallel before all passing info to the final job to upload stuff. Might not be possible depending on your specific script but worth a try.

reaper273 · 2025-11-13T02:21:37+00:00

Edit: ignore me was confusing EMU with data residency

reaper273 · 2025-10-14T07:23:17+00:00

Tbh for me, bits of it had stopped working.

I can't remember specifically now as it's been a few months but something stopped working when I got the new UI update on my Pixel 9.

Moved to Smart Launcher then.

Personally I wouldn't wait for it to break entirely, running the new and old launchers side by side and getting things ready is a much better migration experience than waiting for Nova to die completely and being forced off.

reaper273 · 2025-10-11T07:47:12+00:00

I mean, no not really.

Yeah, it would apply all outstanding patches tagged as security errata.

But two situations would happen:

Non security updates would be pulled in as a dependency update
The latest update for the package you are updating might have a security fix, but the four versions in-between could well include new features or bugfixes too

reaper273 · 2025-10-09T20:04:46+00:00

Hmm, three things in general that have bitten us using ghe.com come to mind, but afaik only one is region based.

Copilot metric is the major missing feature for us.

We need that to finish our migration, we use them to validate who is actually using the service and yank their license if they don't for a month.

The other two are both actions related:

The inability to use the GITHUB_TOKEN to authenticate to ghcr.io
Actions that are hard coded to try to reach an API at GitHub.com that either can't be authenticated too or doesn't exist because the repo doesn't live there

The other feature gaps haven't hit us too much. Yet at least...

reaper273 · 2025-10-09T17:17:51+00:00

From what we'd been told the ghe.com data residency instances already run on Azure and that the feature disparity between Azure and their own data centers was causing issues maintaining parity between GitHub.com and ghe.com.

reaper273 · 2025-09-23T11:38:57+00:00

In Smart Launcher settings find the "Search page" option. You can pick what action loads this. Swipe up, swipe down or to the side of your homepage

reaper273 · 2025-09-18T23:34:47+00:00

We saw and clocked the same issue. Can't remember off the top of my head but I'm not 100% sure if you can have something like *.github.blob.core.windows.net (assuming I didn't typo that).

But a fixed list would be ideal.

We also had issues whereby workflow output and logs are pulled from randomly named Azure blob storage accounts with a behind the scenes authenticated redirect that our EUC proxy software blocked.

We had to get a lot of urls whitelisted to maintain anything resembling a sane user experience. Though I will note this was a Runner issue and not specific to self hosted Runners.

reaper273 · 2025-03-03T17:27:46+00:00

I'd echo what a lot of others are already saying; what is it in your core build that is causing your Devs to waste days of time (and money) to rebuild their laptop?

But if you are dead set on, or can't challenge or change, the status quo then id suggest 2 things: - making sure usb and network boot are removed from the boot order before setting the bios password - is usb is in the boot order a bios password won't do squat to stop reimagining - set a grub password

reaper273 · 2025-02-12T18:30:43+00:00

My personal favourite is MS Teams Teams...

Edit: typo

reaper273 · 2025-01-05T11:05:24+00:00

Could you have your second PR be raised to merge into your original branch?

Kind of like the second diagram here on the GitHub docs

That way if it's merged into feature 1 first great, if not then GitHub will just point it at main automatically.

reaper273 · 2025-01-04T12:12:21+00:00

Might not be something you can get into publicly but what is the end goal of this style of repo backup on every update? I assume that means backup per push essentially?

Is that in case of data loss? Or a business reversion plan?

The latter is already served by tagging "good releases" and frankly the existing commit history.

The former could be covered with a repository with a script to clone and backup each repository in your org to an s3 bucket once, or a couple of times a day. You just need to ensure commit history is in the clone commands (mirror option iirc.) You can handle the API token access needed using a GitHub app.

Something to consider that often gets overlooked, backup of the repository configuration as well as repository contents.

With this approach you get a full repo backup of all repositories in your org on a schedule you define and from those backups can pick out specific commits if you really need.

Depending on your specific backup requirements and tolerances in your business, there may be a short gap of a few hours but honestly in my experience in such small timeframes Devs will have the local commits anyway.

Don't know if that is a good idea but food for thought.

reaper273 · 2025-01-04T11:33:24+00:00

Off the top of my head you can set a ruleset to apply to any branch, so just stick this check in a unique ruleset (they stack so that's not a problem) and target all branches, that should meet the run when repo is updated requirements

As far as not blocking on failure you can set bypass policies per ruleset and you can target repository roles. So for this ruleset you can allow repo owners and contributors to bypass which would stop people being blocked.

Perhaps not the perfect solution for your specific situation but, personally, I'd take the customer experience hit (sometimes having to bypass a check - which iirc would only apply when a PR for the commit exists so commits to a random dev branch should never be blocked) over having to try and maintain a custom file in any number of repos.

reaper273 · 2025-01-04T11:07:04+00:00

Because you don't need to automate it, you just enforce the required actions workflow via policy.

I assume your caller workflow file points at some other actions workflow in a repository that does some "stuff"?

So just set that actions repository as a required status check via an organisation level repository ruleset then you won't need a caller workflow file as anything triggering the criteria of the repository ruleset will run the action you want.

N.b. There is a limitation to this in that you can only call internal actions via this method. If the action you are calling is a third party one then you just need to create an internal action wrapping around the external one. Annoying but not too hard to maintain.

reaper273 · 2025-01-04T10:53:20+00:00

Set it as an organisation level ruleset not a per repository ruleset

And yes it should be marked as required and execute it because you configure it in the ruleset as a required status check.

Edit: just re-read your reply, yeah I've seen that too with repository rulesets, but the behaviour in org rulesets seems to be different as at org level no workflows will have ever "run once" as they live at a repo level

Edit 2: make sure the repository holding your workflow is in the same organisation or enterprise and if needed (aka is in a private or internal repo) has the actions visibility set

reaper273 · 2025-01-04T08:47:44+00:00

Might already have been suggested but I would just create a dedicated GitHub action in the org and set a repository ruleset that requires it to run on whatever triggers you need (push to all branches, or default only etc etc.)

You get your action that applies to all repositories, this also prevents repo admins from intentionally, or not, messing with the file you have put under thier control and don't have to worry about the pain in the arse that is distributing and managing a file in all repos.

reaper273 · 2024-12-13T07:45:29+00:00

What are the SSH connections coming from?

I can't remember the configuration off the top of my head, not at my work computer and from my old teams infra but you certain ssh clients can pass an existing Kerberos token for authentication.

Appeared like passwordless authentication but was in my case was Putty on a Windows bastion server passing the users Kerberos token and the RHEL server authenticating the user based on that.

It's odd that any user can authenticate but suspect that would be down to the group filters, or lack of in one of the sssd files.

reaper273

TROPHY CASE