If you make a feature proposal issue requesting historical CI minute data be included in the CI minute quota, I’ll gladly help by applying labels used to prioritize work and get relevant GitLab teams involved in finding a solution.
Not sure why it would need to be a “Feature proposal”. Seems like an obvious feature that would be needed.
Think about how people could draft a budget for their managers if they don’t know what budget will be needed? (Assumedly the budget proposal would be Option 1: Pay Gitlab, Option 2: setup internal CI/CD facility.) As long as Option 1 can be shown to be cheaper it would be a no brainer.
So Linds. I use Gitlab with a collegue of mine, very happy with it btw, and got this e-mail from gitlab that CI/CD minutes are changing. I don’t what CI/CD is but Googled it. (Maybe something you would want to link it even if it’s kind of straightforward for millenials? Is that like committing and pulling to gitlab…in a continous way? How does that translate to 400 minutes even in big projects? It doesnt feel that this specific e-mail is the concern of every Gitlab user but I just want to make sure. Thank you in advance for answering my silly question.
Hi everyone,
First, thank you for building this incredible tool that Gitlab is (that may only need a shortcut to navigate beetween commits of a merge request ), and providing free access to some of these incredible features.
Now, as I currently use GitLab SCM + CI + CD (around 1k-1k5 minutes a month)
As I work for a non profit organization that works alongside homeless and poor people, and this change will most certainly impact us, I wonder if you plan to apply some exceptions or solidary billing on these usages quotas for non profits organization ?
Thanks
I honestly wish that before making this change you had addressed the workflows of purchasing additional minutes. I almost bought extra minutes one month when I was approaching the limit, but it was so unintuitive that I thought it was broken and gave up. https://twitter.com/tecknicaltom/status/1273459732351561728 - I should be able to give you a cc and you give me minutes. Don’t make it difficult for people to give you money. (PS, I registered on this forum to make this post. Same deal, why do I need to confirm my email address when I logged in with my gitlab account?)
Hi @paspalas thanks for the feedback. We will consider including this in future communications.
From our pricing page: Pipeline minutes are the execution time for your pipelines on GitLab’s shared runners. Execution on your own runners will not increase your pipeline minutes count and is unlimited.
Hi @thibaut.cheymol - thanks for writing in with your feedback. So glad you love GitLab!
Currently - we have programs for Open Source, Education and Startup programs and do not have one for Non Profits. We do generally see the value in non-profits and we hope to create some sort of a non-profit offering in the future. Consider providing your feedback in this issue for non-profits.
I’m involved in several open source project groups that are using GitLab CI quite extensively. Joining the Open Source Program to get extra CI minutes is interesting, but I’m unclear exactly how this will work wrt contributors.
Our projects use the forking workflow, so individual contributors never have direct access to any of the official project group repositories. Instead they fork the repo, and open merge requests to feed code back from their fork into the primary project repos. All merge requests are required to pass all CI jobs before merge requests are permitted to merge. Due to the forking workflow, the CI jobs are all running in the context of the user’s fork, not in the context of the main project group.
IOW, the only CI jobs that run in the context of the project are the post-merge CI jobs. Everything else ends up running in the contributors personal account. If the project joins the open source program, that give more minutes for the post merge CI jobs, but does not appear to help our contributors who are running CI jobs from forks.
Given that the project requires CI to complete before accepting a merge, if a contributor runs out of free CI minutes, they will be unable to contribute to the project, even if the project is part of the open source program. It feels like the open source program ought to be able to cover this forking workflow scenario somehow. Am I missing something in this respect ?
I would also note that registering custom runners to a project is not a simple way to deal with the reduced CI limits. The custom runners can only run jobs that are directly associated with the project against which they are registered. They are not able to run jobs for any users’ forked repos. This makes sense from a security POV, as you don’t want a custom runner to be abused by anyone, but it significantly limits the usefulness of custom runners for projects with a forking workflow.
This problem is not unique to gitlab CI, and I’ve noticed other platforms often deal with this by requiring a project administrator to approve running of jobs when receiving submissions. It would be very useful if GitLab supported something like this so that custom runners from a project can run jobs on a merge request submitted from a user’s fork. This would solve a big usability problem with providing CI envs for non-Linux OS and lessen the impact of the reduced CI minutes on shared runners.
Our team is on the free tier and currently uses gitlab for SCM + CI/CD. In my analysis back in May this year, I figured out that probably the Bronze tier would be the appropriate choice for us.
Has it been dropped? If so, I think we have to stick with the free plan and top up the minutes every now and then. Silver tier is not feasible for us.
Hey @tecknicaltom thank you for contributing, I appreciate your candor! I am the Product Manager for Fulfillment which focuses on the purchasing and provisioning experience. We are diving into several purchase flows including CI minutes looking to uncover opportunities for improvement.
If you’d be willing to connect for a 30-minute call to discuss the challenges you encountered, that would be super helpful. If you’re interested, please ping me at arueda@gitlab.com.
Unfortunately, this limitation can cause weakening of GitLab’s competitiveness compared to other competitors… Nevertheless, I do not object to this limitation, as I recognize the burden of GitLab.
However, I’m wondering if GitLab is looking for a way to complement this. I think one way is to provide free tier with features (i.e. multiple assignees, reviewers, etc.) instead that are less burdensome to GitLab and that give users great convenience. I hope to hear GitLab’s thoughts. Thanks.
Should this limit be per project and not per group? Because I worry that this will lead to proliferation of groups with one project inside of them, for people to get maximum of time. Which will lead to higher occupancy of the top-level GitLab namespace.
Answer by @nuritzi didn’t really address the question by @mattia.basaglia. So does this limit apply only to private projects? Because current language of the open source program read like public projects have a Gold limit automatically. Will this still be true?
And this is to me a major issue with this change. Because MR CI runs run against the fork’s group this becomes a problem for open source. Especially if the limit is per group. This means that all forks I create to my personal namespace will compete for some minutes. Does this mean I will have to create random groups to fork projects into?
In fact, I am most concerned about this. As @mitar mentioned, the CI/CD time limit for public projects restricts individual participation in open source projects, so it seems that GitLab CI will be no longer suitable for open source projects on gitlab.com unless self-hosting.
I’ll let someone else respond to the question about namespaces. I do know that GitLab has an abuse department that looks for multi-group creation abuse though.
The Gold project vs Gold group feature offering is something that’s confusing and we’re trying to improve, so I can see why you’d have this question. Here’s more information:
What are Gold features?
First, I’d like to clarify the distinction between GitLab’s features and the CI minutes that we offer. These are separate.
Gold features refer to the list here: Self-Managed Feature Comparison | GitLab You’ll notice that the list does not mention the amount of CI minutes per tier. Instead, we mention the CI minutes per tier on the main pricing page: Pricing | GitLab
Gold features per project vs per group
As you mentioned, Gold features are automatically provided at the project level to publicly visible projects.
However, there are some Gold features that only apply to groups. Those are features like roadmaps and epics. Here’s the list of group level Gold features (the side bar has the list). So, if an open source project needs group-level Gold features, they’ll need to apply to the open source program.
We don’t want to make it harder for people to contribute to open source projects on GitLab. Thanks for the feedback you’re providing!
I believe that due to a known bug, public projects’ CI minutes are not being counted. This gives us some time to think through the open source contribution story in regards to the new CI minute change. That means that only Free accounts with private projects will see an immediate impact to their CI minutes.
I’d really like to see that it keeps getting easier to contribute to open source projects on GitLab, so again, thanks for the feedback!
This makes sense. Thanks for this explanation. Can I suggest this is added to open source program description somewhere? So this difference between gold project and gold group? I was confused with this before, also because you cannot really obtain information about the plan your project belongs to. It would be great if I could somewhere written “plan: gold” for public projects. (Or is it there?) And then for public groups there would be some other plan listed.
Good idea! I’m in the process of making several changes to the GitLab for Open Source landing page. I’ll try to add more about that there for now. I just added a note to myself about that in the work-in-progress MR I have for an update to that page.
I personally think that there should be more information about Gold groups vs projects on the pricing page though. I have this proposal in an issue here: Suggest update of GitLab’s comparison page.
I don’t think we have that in the works, but I think it’s a good suggestion. I created this issue just now taking your comment as inspiration.
As an FYI, we may need to turn that into a confidential issue if the corresponding team picks it up and starts talking about pricing or business strategy. I wanted to show it to you before that happens in case you have further input.
It’s possible we already have some of that, so someone may chime in with more info.
(that may only need a shortcut to navigate beetween commits of a merge request 
), and providing free access to some of these incredible features.
(around 1k-1k5 minutes a month)
thank you for contributing, I appreciate your candor! I am the Product Manager for Fulfillment which focuses on the purchasing and provisioning experience. We are diving into several purchase flows including CI minutes looking to uncover opportunities for improvement.
Thanks.