Replies: 16 comments 14 replies
-
|
Yes, I definitely agree that we need this feature ASAP. Currently using GitHub-hosted runners in Australia and would desperately want some runners in the same region that our product is deployed in. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback - I can understand your desire to select a region for your runners. We have this on our backlog, but we don't have any immediate plans for this. |
Beta Was this translation helpful? Give feedback.
-
|
Any ETA about this feature ? It's a must-have ! :) |
Beta Was this translation helpful? Give feedback.
-
|
@aramfe fwiw, running self-hosted runners on ECS/Fargate as a service for the past 6months or so has been more or less completely maintenance free. The runner agent self-updates by default and the container's init script auto-registers on startup, which allows me to scale the runner instances up and down (I use an EventBridge scheduled task to scale up to 10 runners during business hours and back down to 1 off hours). I also chucked an API call in to deregister any offline runners into the init script, automating the cleanup within the same process. You can't run any Actions that rely on Docker, but for E2E and browser tests (and pretty much most things), that's not been a problem. |
Beta Was this translation helpful? Give feedback.
-
|
This has already been requested several times in the past:
We also absolutely need the ability to pin the region to be able to utilise GitHub-hosted runners for our data processing workloads due to GDPR compliance requirements. With the new powerful runners that have just been released, it's essential that you implement this so that many users can make full use of it for other purposes than CI as such. |
Beta Was this translation helpful? Give feedback.
-
|
Any updates? Would also like the ability to have github workflow actions running from australian servers. |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this please? (request for Australian region). Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this? Some websites ban US IP addresses and then all RESTful requests return HTTP 451 error, need this feature ASAP |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Any update on this? |
Beta Was this translation helpful? Give feedback.
-
|
hi, Any update on this? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I definitely agree that we need this feature as soon as possible. Currently, we are using GitHub-hosted runners in Australia. However, we urgently need runners located in the same region where our product, WhatsApp Plus, is deployed. |
Beta Was this translation helpful? Give feedback.
-
|
It will be helpful because we can run some regular jobs on the respective regions. Such performance gain is massively and we do not need to configure the dedicated runners anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, we do not have plans in the next 3 months to enable regional actions runners. Thank you all for the feedback ad follow up. I will follow up here in 3 months time with an update in this space. |
Beta Was this translation helpful? Give feedback.
-
|
Hi team, any updates on this? This feature could be a big deal for GitHub Organizations located outside U.S. |
Beta Was this translation helpful? Give feedback.
-
|
It would be very beneficial now that there's a cost for using self-hosted runners. I use self-hosted because some hosting companies restrict ssh access to their servers from IPs not in Brazil. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Right now GitHub-hosted runners are located in the US only.
This leads to massive latency issues for HTTP requests against servers in non-US regions like Europe.
In our case, especially our end-to-end tests, which run from GitHub-hosted runners against our deployments in an ECS cluster in Europe, are heavily impacted by these location-induced latency problems: The tests not only got very flaky, but are also extremely slow in their execution time. While the tests run locally in like two minutes, they take like eight minutes on GitHub Actions. Even with sharding and parallelizing them, they are still much slower than expected.
Before we switched from AWS CodePipeline to GitHub Actions, we've never encountered these kind of problems, as CodeBuild runners were always hosted in the same region, the pipeline was defined in. We actually expected this to be the case here as well. One of the main selling points for us, was the performance of the GitHub runners themselves: They are very fast and also very stable. Having self-hosted runners on the other hand, would lead to a lot of maintenance overhead. Well. Not having runners in the same region our product is deployed in, basically forces us to setup self-hosted runners -> Which is obviously diminishing this selling point completely.
I hope for a solution regarding this, as I think that this is heavily needed for non-US users as well.
Beta Was this translation helpful? Give feedback.
All reactions