<3
On Fri, Oct 16, 2020 at 3:15 AM Aizhamal Nurmamat kyzy
wrote:
> Let me start pulling internal strings and i will report back.
>
> On Tue, Oct 13, 2020 at 1:42 PM Jarek Potiuk
> wrote:
>
>> Really hard to say now. But I did some - rather generic - calculations
>>
Really hard to say now. But I did some - rather generic - calculations
https://cloud.google.com/products/calculator#id=abb18f23-0ea5-495e-a1fc-9cca1953096b
and is some 400 USD /month. But I think when we connect it with free tier
from GA, it could be half that I think.
J.
On Tue, Oct 13, 2020 at
What are the estimated yearly costs?
On Tue, Oct 13, 2020 at 9:17 AM Jarek Potiuk
wrote:
> Yep, we can do it: *docker build --cpu-shares=100 --memory=1024m *
>
> On Tue, Oct 13, 2020 at 6:15 PM Jarek Potiuk
> wrote:
>
>> Plus the "workflow_runs" (image building) for all PRs can also be done in
Yep, we can do it: *docker build --cpu-shares=100 --memory=1024m *
On Tue, Oct 13, 2020 at 6:15 PM Jarek Potiuk
wrote:
> Plus the "workflow_runs" (image building) for all PRs can also be done in
> the self-hosted workers. They are safe as they are using master scripts
> (the only potentially
re: security conerns, this is a case where we could require committer
approval before running full tests (though leaves the risk that a PR is
approved for testing and then the user adds something concerning after).
via Newton Mail
Plus the "workflow_runs" (image building) for all PRs can also be done in
the self-hosted workers. They are safe as they are using master scripts
(the only potentially dangerous part in them is that someone could do some
"mining" as "malicious" Docker image building step, This is the only part
I think this part is easy:
* First of all - It is similar to GA - someone could have used all the 180
workers of Apache by submitting PRs to various projects. So we just need a
limited worker queue. All those can run as workers in GKE and it should be
easy to manage (we could have auto-scaling
Yep. Now we just need credits :)
On Tue, Oct 13, 2020 at 5:30 PM Kaxil Naik wrote:
> That's ace, we should go ahead with self-hosted runners then.
>
> On Tue, Oct 13, 2020 at 4:06 PM Ash Berlin-Taylor wrote:
>
>> Confirmed, we *can* do it - Arrow has done it already
>>
That's ace, we should go ahead with self-hosted runners then.
On Tue, Oct 13, 2020 at 4:06 PM Ash Berlin-Taylor wrote:
> Confirmed, we *can* do it - Arrow has done it already
> https://issues.apache.org/jira/browse/INFRA-19875
>
> But lets have a think on how to not be a bot net :)
>
> On Oct
Confirmed, we can do it - Arrow has done it already
https://issues.apache.org/jira/browse/INFRA-19875
But lets have a think on how to not be a bot net :)
On Oct 13 2020, at 3:59 pm, Ash Berlin-Taylor wrote:
> I've spoken to a few members of ASF Infra directly, and they are just
> confirming
I've spoken to a few members of ASF Infra directly, and they are just
confirming but they are okay with the idea of us adding self hosted runners to
our repo, and also okay that we can manage those nodes ourselves. Should get
final confirmation today.
I wanted to double check that we could use
This is also a slight problem as mentioned in the build@ thread:
https://lists.apache.org/thread.html/r1708881f52adbdae722afb8fea16b23325b739b254b60890e72375e1%40%3Cbuilds.apache.org%3E
- managing hosting runners has to be done through infrastructure and they
are not really responsive recently (I
I've thought about private/self-hosted runners, and I think long term that's
the way to go to alievate our CI bottlenecks.
There's a bit of work we need to do around security of builds - as mentioned
here
Hello Aizhamal, Everyone,
We've had some problems recently with concurrency for Github Actions and
suggested solution for now is to use self-hosted runners (This is suggested
by GitHub Support)
I made some comments in the issue here:
https://github.com/apache/airflow/issues/11496
And also
14 matches
Mail list logo
