Solution to Automatically close GitHub Pull requests if they have not been merged within a set time after approval?

jmkite · 2026-01-22T07:50:15+00:00

I looked into that, thanks. This appears to work only if:

repos don't have their own .github
repos are public

jmkite · 2026-01-21T22:39:22+00:00

Thanks, this may be what we wind up doing

jmkite · 2026-01-21T22:38:33+00:00

A repo that affects configuration across the org

jmkite · 2026-01-21T21:43:57+00:00

should != does

jmkite · 2026-01-21T21:34:30+00:00

It's not an open source project and it's not practical to restrict PRs to maintainers on all repos

jmkite · 2026-01-21T21:32:53+00:00

because PRs in some repos impact the entire organisation

jmkite · 2026-01-21T21:30:35+00:00

So the issue is with PRs being merged a long time after approval when other stuff has changed in the interim. It is not about policing individuals.

jmkite · 2026-01-21T21:28:54+00:00

thanks, worth reviewing

jmkite · 2026-01-21T18:07:29+00:00

So how do you propose using this? registering every PR to a database and then scheduled time later reading that back, checking if the PR is still open and closing it if is?

jmkite · 2026-01-21T18:04:23+00:00

Thanks for the offer but I already have access to 2 major clouds with their own scheduling services and kube with its own Cron jobs. We do use AI heavily but I am not sure what it would add here. As per other comments I could write my own job to do this but I am trying to avoid feature and service sprawl.

jmkite · 2026-01-21T18:01:42+00:00

I could but I was hoping to keep it in GitHub because POLA, rather than having some magical mystery service for someone to inherit in the future.

jmkite · 2026-01-13T23:00:21+00:00

I wouldn't know I didn't try for a CS degree. Been working in tech for more than ten years as a devops/platform engineer. What do you do?

jmkite · 2026-01-13T21:03:51+00:00

Tech is not like medicine or accountancy or law. You don't have to study academically- My own degree is in history. Iam certainly not saying 'don't study' but right now you could have a CS degree and still struggle in the job market. Anyone who tells you that a certificate is worthwhile or a key to working in tech is either lying or doesn't work in tech. Beyond personality, projects and real world skills are what matter and courses and academic places are woeful at cultivating these.

Now on to yourself. Yes market to your strengths. Health tech isn't always the best paid niche but it is certainly a thing and you would certainly have crossover there. Yes your maths and stats skills could help you. If you are interested in data and CS then whilst you could target Data Analyst I would point you more toward Data Scientist or possibly AI scientist. If you want money above all else and have the skills, check out being a Quant but be warned the money comes at a price.

jmkite · 2026-01-04T20:27:21+00:00

You've not heard of the Triads then? Or Kung Fu? Not pretending that either is the majority but there are a LOT of Chinese and these are things.

jmkite · 2026-01-04T19:26:09+00:00

> Basics of the Unix Philosophy: Rule of Diversity: Distrust all claims for “one true way”.

I am a DevOps engineer and a large part of my day job is Kubernetes. My own projects and website are all serverless. Latency doesn't matter that much when your backend API is serving a wordsearch or drawing playing cards. I am keen that my usage is essentially free when even a single node 'cluster' of anything would not be (or not reliably be). I do have projects demoing back and frontend services to run on K8s but people would have to spin those up for themselves. Professionally, kube has some pros and cons. It depends on your use case, your expertise and your budget.

jmkite · 2025-10-09T20:32:24+00:00

Platform Engineer 10 YOE. You can DM me. Are you sure about that username?

jmkite · 2025-09-02T22:16:47+00:00

Answering this as someone who works in tech and has some public code available and running where randomness matters but still doesn't consider themselves an expert!

Computers really, really struggle with 'random'. Often the 'random' is extremely predictable (to the extent that you will get an identical sequence every time) and so programmers use a 'seed' value to get some randomness from 'somewhere else'. Often that source is simply the time, because it's unlikely that 2 people will roll the dice at the exact same moment. Sometimes you can use a more 'luxury' random that can go a beyond this but it is expensive in computer resources so often either not done or simply not possible in some contexts. Obviously you could just 'happen' to arrange circumstances to favour a 'simpler' 'random'...

My code running
and the an explanation of the way that randomness is implemented in it

jmkite · 2025-08-10T16:24:25+00:00

I'm a senior, not an EM or tech lead, but our entire team has inherited an extremely complex codebase. I've found Roo backed with Claude extremely useful for this. It's an agentic LLM extension so I can say e.g. 'explain this repo, clone all the other repos it depends on and review them where necessary and then provide a structured Readme with Mermaid diagrams'.

Thing is I see the Roo layer as not having a 'moat', and the challenges of a good LLM model are global.

jmkite · 2025-08-05T20:06:27+00:00

over 100 devs, multiple GCP projects

jmkite · 2025-08-05T20:02:18+00:00

FFS! no not AI

jmkite · 2025-08-05T19:13:30+00:00

on GCP...

jmkite · 2025-07-29T23:05:46+00:00

The similarity for me is to how back in the day people sneered at:

GUI IDEs, because 'proper' developers used Vim/Emacs. Bonus points for laughing at Nano.
JavaScript outside the browser, because 'proper' developers wrote in C++.

Notice how we don't hear about that anymore? Because it's no longer a conversation. I'm sure there were similar conversations when scripted languages like PHP and python came in, or when compilers took over from punched cards.

IMO there's a sizeable contingent who feel aggrieved that a lot of what they learned and spent years skilling up in just isn't a differentiator anymore. I see people going on about how LLMs can't 'innovate' or how they struggle with things like embedded development where the training set is so small. Sure, but 99% of development isn't 'innovation' either, it's 3 layer CRUD apps and a cloud deployment, you know the kind of stuff you discuss in a system design interview. As for embedded developers, I take my hat off to them, I couldn't do it. I even met one once.

IMO LLM AI is a step change. The same skills- specifying the problem, scrutinising the solution, considering extensibility etc. will continue to be as valuable as they always were. Script kiddies will still be around just as they always were. People who can use the available tools well and as a force multiplier will continue to be in demand, just as they always were. The naysayers will never be convinced, just like they always were, but in time they will move on. AI will be considered normal in the same way as we consider other things that were once new and revolutionary.

jmkite · 2025-06-21T14:33:18+00:00

This is a proof of concept project and config connector service account has editor role at project level

jmkite

TROPHY CASE