6 ms·

GitLab team member here. Thanks for the comment. We understand people don’t want their quotas being filled by something outside of their control. For Open Sour

GitLab team member here. Thanks for the comment. We understand people don’t want their quotas being filled by something outside of their control. For Open Source projects, we have GitLab for Open Source which contains higher limits from the Ultimate tier (250GB Storage, 500GB transfer/month). In addition, we intend to look into other ways to address your concern such as counting only your own traffic or allowing you to limit external traffic.

DoesntMatter22 4y ago
I love the fact that they haven't thought out a lot of how this needs to work. You can't even decide if it's worth sticking with GitLab because they don't even know how they are going to handle half of this stuff.
- nslzk 4y ago
- yunohn 4y ago
  I appreciate their open discussion and iterative approach. There’s no need to get your feathers ruffled. These measures mainly impact users freeloading their services, so maybe have some empathy for the company providing them?
  - Dayshine 4y ago
    > These measures mainly impact users freeloading their services Does it? We use GitLab at work, and we have to use local runners (for regulatory reasons + GitLab runners don't support what we need anyway). Unlike other CI/CD providers (e.g. teamcity), GitLab Runners don't have a local git cache. So if you need to do a clean clone for an important build (gitlab runners don't clean up well after themselves), you need to re-clone the repo from GitLab.com. With a 1:2 ratio for storage vs bandwidth (10GB storage, 20GB bandwidth per month), assuming using 1GB in latest commits, and 2GB total repo size (e.g. a vendored dependency that doesn't change frequently): - 2 runners - Clean once a week - 5% of bandwidth per shallow clone - 40% of bandwidth per month on CI/CD alone. Leaving space for 6 clones by developers (hope you don't upgrade your dev machines often). If you're using a submodule in multiple projects you're going to tear through your bandwidth.
    - yunohn 4y ago
      Like I said, it /mainly/ impacts freeloaders. Having a 1+2 GB git clone is not a common usecase. That being said, it appears that you would not be affected: > Transfer is the amount of data egress leaving GitLab.com, except for: > Paid plans only: self-managed runner transfer and deployments. This is determined by transfer authenticated by either a CI_JOB_TOKEN or DEPLOY_TOKEN (https://about.gitlab.com/pricing/#what-counts-towards-my-transfer-limit https://about.gitlab.com/pricing/#what-counts-towards-my-tra...)
      - DoesntMatter22 4y ago
        Freeloaders... You mean the people they encouraged to use their service and then pull the rug out from under them?
    - dnsmichi 4y ago
      Thanks for sharing for your feedback. I have added more insights into caching and checkout strategies to reduce traffic and speed up job execution in GitLab Runners in this comment: https://news.ycombinator.com/item?id=32408960 https://news.ycombinator.com/item?id=32408960

DoesntMatter22 4y ago

I love the fact that they haven't thought out a lot of how this needs to work. You can't even decide if it's worth sticking with GitLab because they don't even know how they are going to handle half of this stuff.

nslzk 4y ago
yunohn 4y ago
I appreciate their open discussion and iterative approach. There’s no need to get your feathers ruffled. These measures mainly impact users freeloading their services, so maybe have some empathy for the company providing them?
- Dayshine 4y ago
  > These measures mainly impact users freeloading their services Does it? We use GitLab at work, and we have to use local runners (for regulatory reasons + GitLab runners don't support what we need anyway). Unlike other CI/CD providers (e.g. teamcity), GitLab Runners don't have a local git cache. So if you need to do a clean clone for an important build (gitlab runners don't clean up well after themselves), you need to re-clone the repo from GitLab.com. With a 1:2 ratio for storage vs bandwidth (10GB storage, 20GB bandwidth per month), assuming using 1GB in latest commits, and 2GB total repo size (e.g. a vendored dependency that doesn't change frequently): - 2 runners - Clean once a week - 5% of bandwidth per shallow clone - 40% of bandwidth per month on CI/CD alone. Leaving space for 6 clones by developers (hope you don't upgrade your dev machines often). If you're using a submodule in multiple projects you're going to tear through your bandwidth.
  - yunohn 4y ago
    Like I said, it /mainly/ impacts freeloaders. Having a 1+2 GB git clone is not a common usecase. That being said, it appears that you would not be affected: > Transfer is the amount of data egress leaving GitLab.com, except for: > Paid plans only: self-managed runner transfer and deployments. This is determined by transfer authenticated by either a CI_JOB_TOKEN or DEPLOY_TOKEN (https://about.gitlab.com/pricing/#what-counts-towards-my-transfer-limit https://about.gitlab.com/pricing/#what-counts-towards-my-tra...)
    - DoesntMatter22 4y ago
      Freeloaders... You mean the people they encouraged to use their service and then pull the rug out from under them?
  - dnsmichi 4y ago
    Thanks for sharing for your feedback. I have added more insights into caching and checkout strategies to reduce traffic and speed up job execution in GitLab Runners in this comment: https://news.ycombinator.com/item?id=32408960 https://news.ycombinator.com/item?id=32408960