jl-gitlab

You could potentially use a regularly scheduled pipeline in GitLab CI to do this. You'd need to use a user token instead of the pipeline token since you want to push back into the repository, but this should be possible. Then, when GitLab CI updates the repo, Netlify CI should jump in.

In GitLab we have shared group/instance runners now as well as multiproject pipelines.

https://docs.gitlab.com/ee/ci/multi_project_pipelines.html

https://docs.gitlab.com/ee/ci/runners/#shared-specific-and-g...

We are focusing on improving the new user experience here, so OP if you decide to try out GitLab I'd love to hear what works well and what doesn't.

One relatively easy way to debug is to set up a runner instance on your machine and then send jobs that you're working on there. In that way you are validating real jobs, but can also monitor and interact with what's happening in real time.

Features like https://gitlab.com/gitlab-org/gitlab/issues/39527 will make this easier and allow you to do similar troubleshooting in an interactive web terminal.

We have a new PM for the runner and this is on his agenda to research and improve. The reality is that the job execution environment is complex - each job does just have a simple script section which is just shell commands, but there is a lot of context that impacts behavior (to which environment are you deploying, what environment variables are set specific to that environment, is it a protected environment with variables that are shareable to any random user, are artifacts being passed, and so on.) Making iterating on pipelines easier is definitely on our agenda, and adding your thoughts to issues like https://gitlab.com/gitlab-org/gitlab-runner /issues/2226 or making new ones for your specific use case will help. We are also working on other oblique solutions to make pipelines easier to iterate on like https://gitlab.com/gitlab-org/gitlab/issues/39527, which help solve the problem in a different way where you don't need to try to replicate the state of the world on your local environment but can still find and fix problems quickly.

EDIT: I should also mention, https://gitlab.com/groups/gitlab-org/-/epics/2072 is a big priority for us where we want to reduce the time to first green pipeline (not just for new users, but for new projects too). Feedback is welcome there as well.

We are looking to add breakpoints in an upcoming release, building on our interactive web terminals feature. If you're interested in providing feedback the public issue is https://gitlab.com/gitlab-org/gitlab/issues/39527.

Thanks, that's really great to hear. Release evidence, and where we plan to take that feature long term (https://about.gitlab.com/direction/release/release_governanc...) is really exciting to me, having spent a lot of my career in release management. Would be great to get your feedback on where we are headed - even if you aren't a GitLab user today, may you will be in the future.

We are looking at adding many new kinds of packages, including potentially Linux package types such as thesehttps://about.gitlab.com/direction/package/package_registry/...

Interesting list, thanks for sharing. I'm the PM for CI/CD at GitLab, and I don't mean to hijack the topic, but wanted to give a heads up that we are looking at building a feature for these kinds of procedures that aren't quite pipelines, based on Jupyter Runbooks. Would love to hear your feedback: https://gitlab.com/gitlab-org/gitlab/issues/9427

Hey, CI/CD PM here. I'd love to learn more about how you're using GitLab for mobile, if you're up for it ping me at @jlenny on gitlab.com. It's an area of focus for us, and it's always great to get to know another person who is using that use case.

PM for CI/CD here, thanks so much for your feedback! As much as I'm excited about how much you love the product, we can always do better and I'd love to hear your thoughts. Ping me any time (@jlenny) on any issues that are important to you that would make things better.

Ah, I understand. We do have users who prefer the stage model or hybrid DAG mixed with stages, but I get that that isn't your point of view. I do hope that after the next couple releases it becomes something more useful for you - your use case is important too.

Releasing early to get feedback on issues is important to us but we can do better communicating around what's an early preview vs. a mature feature. The maturity page that's linked to in this discussion is actually part of how we are trying to improve our communication around that. This is more at the stage and category level, but features have a maturity level as well and it's worth us reflecting on how that can be made more clear.

We released DAG as an MVC, which helped a lot of people out even in its current state. We do release features here iteratively intentionally, with the idea that feedback will help make future iterations better in unexpected ways compared to if we released a big feature all at once.

The items you mention are scheduled for follow-ups in our epic https://gitlab.com/groups/gitlab-org/-/epics/1716. Your feedback on sequencing or how we are approaching the different improvements is more than welcome.

I would have loved for the feature to be useful for you too in the MVC iteration, and I'm sorry it wasn't. We are still working on it, though, and I hope that it does become valuable for you also. In the meantime you should still be able to use GitLab in the same way you always have - let me know if you're having trouble running pipelines without the DAG.

Hey, I'm Jason - the PM director for this area. I really do appreciate the pings - you can @ me at my username jlenny in issues that are important to you. It's true in general, even for features, but especially for issues a heads up helps us make sure we are prioritizing things in the right order.

I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/64995 - please join us in the conversation there.

Thanks for the super clear description! Doing some internal research on this.

Hey there, PM for CI/CD here. Can you point me to an issue in either GitLab or the Jenkins Plugin repo that has more info specifically on what you're looking to do that isn't possible today? Or share specifically what you need here so I can make one? That other project seems to have a few different features and I'm not sure which use cases exactly are important for you.

In any case, we definitely want to make sure you have the right functionalities you need.

Here at GitLab we're an all-remote company, and it's been that way since the beginning as I understand it. I've been here about a year now and I've heard so many great stories from people who had remote working change their life for the better. A while back I made a space to collect these, if you're interested in this topic you might find some of these inspring: https://about.gitlab.com/company/culture/all-remote/stories/

Very nice! I'm the PM for CI/CD here at GitLab and think this is a wonderful idea. Feel free to reach out if you have any questions or need any support - my contact info can be found publicly on my GitLab profile: https://gitlab.com/jlenny

For transparency I want to start by saying I'm a GitLab employee, but working for an all-remote company has changed my life. More time with family has been the most important, and I'm an expat so being able to travel and visit family overseas has been amazing.

It's hard to describe, but when the entire company is remote it's such a different experience than being one remote person or part of a remote sub-group. The whole company knows how to operate remotely and be effective in that way. I've never seen anything like it, but now I can't imagine working in any other way. If I started a company in the future, I am 100% confident it would be all-remote from day one.

We have a nice page up on our site with people's experiences with remote work. If you're interested in the topic it might be worth reading: https://about.gitlab.com/company/culture/all-remote/stories/

I'm a GitLab employee, and before working here always struggled with remote work. There's a tipping point, though, at an all remote company where when everyone is remote, the communication structures of the company adapt to having clear communication through video, chat, and email. We do a lot of video chat here. It's hard to describe what it's like, but it certainly doesn't feel like we're all locked away in little boxes with only awkward or indirect ways to interact with each other.

These are personal anecdotes, but here at GitLab we recently started recording our personal stories about how remote working changed our lives. If you're interested in remote work you may also find this interesting: https://about.gitlab.com/company/culture/all-remote/stories/

Thanks for sharing, this is really great feedback.

You can actually use it standalone, for example with GitHub repos: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/githu...

(Disclaimer: GitLab employee here)

GitLab CI/CD product director here - we're working towards making includes more flexible to give you a lot more control. Would love your feedback on the small primitives we're looking at here: https://about.gitlab.com/direction/cicd/#powerful-integrated...

This for us represents our vision so far on where we want to take GitLab CI next and I think addresses where you see gaps with our product today - we see them too.

Hey there, CI/CD product director here. We do allow scheduling/editing/deleting pipelines via code, at least via an API: https://docs.gitlab.com/ee/api/pipeline_schedules.html

Or are you looking more for putting the values in the .gitlab-ci.yml itself? This is something we have thought a bit about, but it gets strange with branches and merges where it's not always clear you're doing what the user wants as the different merges happen.

To your second point, you might be interested in some of the primitives we're looking at building next here: https://about.gitlab.com/direction/cicd/#powerful-integrated.... These, in concert, will help with a lot of more complex workflows.

Thanks for the incredible feedback! CI/CD product director here. A few thoughts:

- Templates

We actually have done a lot here recently, we've improved includes so that they have a lot more flexibility (https://docs.gitlab.com/ee/ci/yaml/#include), and have even refactored our own Auto DevOps implementation to take advantage of this: https://docs.gitlab.com/ee/topics/autodevops/#using-componen.... In this way, you can have included behaviors across your projects that can then be updated in bulk.

- Build results

We are planning on adding testing results over time in our vision for this year, thank you for confirming this is important from your point of view. https://gitlab.com/gitlab-org/gitlab-ee/issues/1020

- Overall view of runner status

We did recently add pipeline info to the operations dashboard (https://docs.gitlab.com/ee/user/operations_dashboard/), which I know isn't exactly what you're looking for here but we are making progress in this direction and recognize the gap.

- Dashboard

The next improvement we're making to that operations dashboard is adding environments. You can see the in-progress issue here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3713

- System wide configs

This can be achieved by using includes to set the variables, which is admittedly a workaround. We do have an open issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/3897) to implement instance level variables that would solve this.

- Extensibility

This is an interesting one because Plugins are, at least in my opinion, what makes Jenkins a mess to use in reality and believe me, I've managed plenty of Jenkins instances in my career with lots of "cool" plugins that do something great, at least while they work. It is one of our values that we play well with others, though, so I'd be curious to work with you to understand specifically what you'd like to be able to make GitLab do that can't be done through your .gitlab-ci.yml. Our goal is that you should never be blocked, or really have to jump through hoops, but still not have to be dependent on a lot of your own code or third party plugins.

You may find our direction page for CI/CD at GitLab interesting if you're looking to learn more about the possibilities involved here. We do all of our planning and roadmapping in public so you read a bit about our overall technical challenges and approach there, and drill down into the stages (CI, packaging, and CD) that make up the capabilities within GitLab, each of which have their own videos and other planning content.

https://about.gitlab.com/direction/cicd/

GitLab product director for CI/CD here - thanks so much for the feedback, everyone. It's really great to read how much you're getting value out of what we built.

We have an overall CI/CD direction page up at https://about.gitlab.com/direction/cicd which you can drill down into the individual stages plans from. Feedback is always welcome, we love building things in partnership with real users. You can reach me at jason@gitlab.com any time.

We're building some similar tech at GitLab, though without the dependency analysis yet.

Merge Requests now combine the source and target branches before building, as an optimization: https://docs.gitlab.com/ee/ci/merge_request_pipelines/#combi...

Next step is to add queueing (https://gitlab.com/gitlab-org/gitlab-ee/issues/9186), then we're going to optimistically (and in parallel) run the subsequent pipelines in the queue: https://gitlab.com/gitlab-org/gitlab-ee/issues/11222. At this point it may make sense to look at dependency analysis and more intelligent ordering, though we're seeing nice improvements based on tests so far, and there's something to be said for simplicity if it works.

Yes, this is something we're definitely investigating! We have an issue open at https://gitlab.com/gitlab-org/gitlab-ce/issues/55840, please join us in the conversation there if you have thoughts on how we can do this in a way that works well for your use cases.