GitLab technical evangelist here.
I can't seem to reproduce this - maybe it's uBlock Origin? Are you sure it's the default configuration? What were the requests to - just to the main HTML page?
487 karma · joined October 12, 2017
I can't seem to reproduce this - maybe it's uBlock Origin? Are you sure it's the default configuration? What were the requests to - just to the main HTML page?
Could you DM / email me the details and a screen shot? I’ll try and help as best I can.
Short answer: yes.
Long answer: Also yes, but with a link to the relevant epic: https://gitlab.com/groups/gitlab-org/-/epics/2875
It could be that there is a legit email provider that got on the banned list inadvertently. Would you mind sharing the provider?
If you want to not do it in public you can DM me at olearycrew on Twitter or email boleary [at] gitlab.com
You can install GitLab and only _use_ it for 'git' (source control management). But the install is the same - GitLab is a single application
You can host NPM registries in your GitLab projects. https://docs.gitlab.com/ee/user/packages/npm_registry/
Moving to Core (free AND open source) soon along with 17 other features: https://about.gitlab.com/blog/2020/03/30/new-features-to-cor...
They are commitments. Each feature has its own issue for the engineering effort behind moving it to Core with various milestones based on team capacity and complexity of the move.
You can track each with the table in the post that relates the feature to “GitLab issue” that represents the move.
That's super valuable because you get started faster - e.g. "oh here's how I can deploy a lambda" but brings up this security concern of running other people's code. As discussed in the article, this is something NPM solved after the left-pad debacle. And I am sure (I hope) that GitHub will either change the documentation or add features to prevent this.
Yes - if you bring your own runner to GitLab.com you can run unlimited build minutes on it - the build minutes we count are only those on our shared compute (2000 minutes for free, etc.).
The other huge benefit is that you can put that runner behind your firewall without poking any holes - itbjust needs access to GitLab.com and it can run your builds.
[1] https://about.gitlab.com/handbook/communication/#say-thanks
> It saves people commuting time and gives them more flexibility to care for family, go to the gym at a convenient time, travel more, and deal with sick children.
I have 4 young children at home. When I came back to GitLab after having my fourth I noted in our Thanks channel - 'Much easier transition coming back from paternity then I’ve ever had. Being at home & being able to step away to help is so much better than commuting into an office and not being able to help at all.'
Thanks for your feedback on NPM registry support in GitLab. We release minimal viable change (MVC) and then iterate on our product functionality. Here are some of the issues we have related to NPM support:
https://gitlab.com/gitlab-org/gitlab-ee/issues/10024 https://gitlab.com/gitlab-org/gitlab-ee/issues/10050 https://gitlab.com/gitlab-org/gitlab-ee/issues/9164 https://gitlab.com/gitlab-org/gitlab-ee/issues/9104
Can I ask where you're hosting your code today? We offer first-class support for external repositories stored on GitHub with GitLab CI/CD for GitHub [1]. In addition, you can do similar CI/CD integration with any git repository by URL as well [2]. We see both of these as "minimal" integrations and we're hoping to add more first-class support for external repositories this yeah - but would love to know what you'd focus on first if you were Product Manager for a day :smile:
[1] https://about.gitlab.com/solutions/github/
[2] https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/githu...
I agree! I think that we have lots of improvements to make here. One feature that is underutilized (more on that in a second) that tries to answer this is our [1] interactive web terminal that lets you connect directly to the container or runner that is running a job. Would love feedback on how that could maybe help here.
Now, having said that there are two issues still open that are top of mind for making this minimal viable change much more usable. One is making the Web Terminal work in our shared runner pool on GitLab.com [2]. This is obviously required for users of .com who don't want to bring their own runner and something we're working closely with our Production and Security teams on making a reality.
In addition, there is a command today of `gitlab-runner exec` that allows you (in theory) to install the GitLab runner locally and execute it on your development machine. However, we technically depreciated that and have plans to re-implement it in a more useful way. [3]
[1] https://docs.gitlab.com/ee/ci/interactive_web_terminal/
This is really valuable feedback, thank you for it. It's something we are thinking about and working on fleshing out a vision for. Two epics we have around these ideas include [1] Making CI lovable for monorepos and [2] Making CI lovable for microservices.
Both of these challenge our current assumptions around the project::pipeline relationship and will help make room for improvements around that model and provide flexibility to build more complex models that work for "real world" problems like the ones you've stated. However, I don't believe we have all the answers yet so I would love more feedback on these and the issues attached.
I'm not super familiar with Circle CI's SSH debugging, but we do have a feature called "Interactive Web Terminals" https://docs.gitlab.com/ee/ci/interactive_web_terminal/.
This allows you to connect to a terminal in the running job on GitLab CI for debugging. Would love to understand how this does or does not meet your use-case here.
Yes - that's something we want to get to this year. We call it "CI Views" right now but we want to expose better all the types of test results that get collected by GitLab. Today for XML (JUnit) results, you can see what fails in the merge request with https://docs.gitlab.com/ee/ci/junit_test_reports.html.
But we want to make the XML, JSON or HTML output of _any_ type of test first class with CI Views: https://gitlab.com/gitlab-org/gitlab-ce/issues/35379
Thank you for this feedback - it’s something we’re thinking about a lot too. We’ve made some improvements for monorepos (`changes:` keyword) and for micro-services/multi-repo (`trigger:` and `dependency:` keywords) but we’re not satisfied!
We have two open Epics - one for making CI lovable for monorepos (https://gitlab.com/groups/gitlab-org/-/epics/812) and one for making CI lovable for microservices (https://gitlab.com/groups/gitlab-org/-/epics/813). Would love community feedback on the direction those will take us and how we can up level lovability even more.
I agree that a lot of complex pipelines can be tough to express in YAML. One of our key focuses this year is to make advanced use cases for GitLab CI/CD more lovable. Specifically, you can see the overall direction here: https://about.gitlab.com/direction/verify/. Some specific issues I'd love feedback from the community on that I'm thinking about are:
* Directed acyclic graphs (DAG) for pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/47063
* Make it possible to use any language to generate `.gitlab-ci.yml` and pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/45828
* First class support for multiple pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/28592
* Self-modifying pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/44199
(edited for readability)
Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself. If you want you can reach out to me on Twitter @olearycrew or my email is boleary [at] gitlab.
IThere is a boardroom dedicated to GitLab where board meetings happen. But even for each of those, there is a zoom bridge for remote executives to join: https://about.gitlab.com/company/visiting/
Sounds like that is solved.