falsedan

oh that makes sense. I thought the OP was suggesting running CI locally instead of a workflow on remote runners

a display of great wisdom, nice

top tip: make a repo in your org for pushing all these nonsense changes to, test out your workflows with a dummy package being published to the repo, work out all the weird edge cases/underdocumented features of Actions

once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'

> You can run all your CI locally

if you can, you don't need CI. we can't (too slow, needs an audit trail)

I don't think you're responsible for anything more than your own comments.

I added some context that contradicts your assumption that the increased fees were to cover hosting/storage/scheduling costs.

> Having your commits refer ticket ID from system that no longer exists is royal PITA

just rewrite the short links in your front-end to point to the migrated issues/PRs. write a redirect rule for each migrated issue/PR, easy

hard-coded links in commit messages are annoying, you can redirect in the front-end too but locally you'd have to smudge/clean them on local checkout/commit

we don't need it. we need to run our CI jobs on resources we manage ourselves, and GitHub have started charging per-minute for it. apples and cannonballs

> If you think that's easy

I think it's cheap to maintain. let me know how many devs you have, how many runs you do, and how many tests (by suite) you have, and I can do you up a quote for hosting some Allure reports. can spread the up-front costs over the 3-year monthly commitment if it helps

I'm seeing wonky webhook deliveries for Actions service events, like dropping them completely, while other webhooks work just fine. I struggle to see what else could be responsible for that behaviour. it has to be the case that the Actions service emits events that trigger webhook deliveries & sometimes it messes them up.

no, I'd cut the monthly seat cost and grow my user base to include more low-volume devs

but realistically, publishing a web page is practically free. you could be sending 100x as much data and I would still be laughing all the way to the bank

I don't want to shit on the Code to Cloud team but they act a lot like an internal infrastructure team when they're a product team with paying customers

I think you could learn a lot about the other use cases if you asked some genuine questions and listened with intent

it's not the runners, it's the orchestration service that's the problem

been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered

we've got it now that we can detect a GitHub Actions outage and let them know by opening a support ticket, before the status page updates

if you were paying me a monthly license fee for each developer working on your repos, I'd probably consider it