4 ms·

We(as in everyone) are in a serious need of a new git server product. Just do git serving, and do it well. Preferably in a way multiple nodes can be run active-

We(as in everyone) are in a serious need of a new git server product. Just do git serving, and do it well. Preferably in a way multiple nodes can be run active-active for scaling and reliability. No need for cicd (Jenkins is fine for that, thank you very much). What are minimum viable features for me? Granular (per branch) security access. Integration with AD federation and other auth providers(congnito, aws iam) and ability to give AD groups rights. Web hooks sending and receiving. For example launch a merge request webhook(to lambda via aws api gateway, or to Jenkins). Receive a webhook as merge request approval when some Jenkins job finishes. There is exactly zero need for your repository system also run cicd jobs. It ends up doing both tasks badly. You'd like an example of said badness? Ok, how about this: in gitlab enterprise if you create cicd jobs/pipelines there is no way to giving someone an ability to run that pipeline without giving that person ability to push to the repository and submit merge requests. Yes, you can then set it so approval is needed before merge, protecting said pipeline, but why? There has been a ticket on gitlabs own issues page about it for years and it is still not resolved. But wait, there is more... Gitlab enterprise has no mode of working that let's you have more than one active server at a time so goodbye horizontal scaling. You want to scale your cicd worker nodes? They want you to use docker mashine(a deprecated product) instead of writing a Plugin like ec2-fleet for Jenkins. It is obvious gitlab tries to funnel it's enterprise customers into saas.

thiht 3y ago
> Jenkins is fine for that As someone who managed hundreds of Jenkins instances from 2016 to 2018, Jenkins is now complete crap, stop using it. It was an ok product when the open source world offered no alternative but it's completely outdated compared to today's solutions. Deploying it sucks, its config as code format(s) are awful, the plugins are shit, upgrades can (and do) break everything, and I won't even saying anything about the design (not just the UI but also the UX and concepts). Jenkins is not fine for anything in 2023.
- Roark66 3y ago
  What alternative would you suggest? None of the large companies I worked at used anything other than Jenkins for cicd (well in one place we did use azure devops server - back then called teams If I remember correctly, but that was just for one app development team). Where they didn't use Jenkins they didn't have a dedicated cicd runner and they used github/gitlab instead. Both of these (although github less) suck for cicd IMO.
  - thiht 3y ago
    Concourse, Drone, Gitlab CI all work fine. I've also heard of GoCD that looks interesting and looks like an actual "Jenkins successor" (more than an alternative IMO), but I've never used it.
dnsmichi 3y ago
Thanks for your feedback. GitLab team member here. > We(as in everyone) are in a serious need of a new git server product. Just do git serving, and do it well. Preferably in a way multiple nodes can be run active-active for scaling and reliability. No need for cicd (Jenkins is fine for that, thank you very much). You can integrate Jenkins into GitLab. https://docs.gitlab.com/ee/integration/jenkins.html https://docs.gitlab.com/ee/integration/jenkins.html Suggest considering a migration to GitLab CI/CD in your migration planning, following the updated documentation: https://docs.gitlab.com/ee/ci/migration/jenkins.html https://docs.gitlab.com/ee/ci/migration/jenkins.html and more automated imports in https://about.gitlab.com/blog/2023/09/26/atlassian-server-ending-move-to-a-single-devsecops-platform/#atlassian-server-end-of-life-migration-made-easy https://about.gitlab.com/blog/2023/09/26/atlassian-server-en... > Web hooks sending and receiving. For example launch a merge request webhook(to lambda via aws api gateway, or to Jenkins). Receive a webhook as merge request approval when some Jenkins job finishes. (FYI) https://docs.gitlab.com/ee/user/project/integrations/webhooks.html https://docs.gitlab.com/ee/user/project/integrations/webhook... and https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html https://docs.gitlab.com/ee/user/project/integrations/webhook... You can trigger a pipeline from external webhooks using a trigger token, and execute an action against the GitLab REST API. The example for triggering pipelines in https://docs.gitlab.com/ee/ci/triggers/#trigger-a-pipeline https://docs.gitlab.com/ee/ci/triggers/#trigger-a-pipeline can be expanded into more actions, i.e. using the API to create MR approvals or comments. For Python, I'd recommend looking into python-gitlab and this tutorial blog post: https://about.gitlab.com/blog/2023/02/01/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation/ https://about.gitlab.com/blog/2023/02/01/efficient-devsecops... > if you create cicd jobs/pipelines there is no way to giving someone an ability to run that pipeline without giving that person ability to push to the repository and submit merge requests. Yes, you can then set it so approval is needed before merge, protecting said pipeline, but why? There has been a ticket on gitlabs own issues page about it for years and it is still not resolved. Please share the URL :) When creating a new GitLab project, the default branch is protected by default, and only maintainer roles can push to the default branch. https://docs.gitlab.com/ee/user/project/protected_branches.html https://docs.gitlab.com/ee/user/project/protected_branches.h... A developer role can create non-protected Git branches, merge requests, and as such trigger a pipeline from a merge request. You've mentioned approval rules as a safeguard already - CODEOWNERS can be an additional way to ensure that review workflows are followed. https://docs.gitlab.com/ee/user/project/codeowners/ https://docs.gitlab.com/ee/user/project/codeowners/ You can also use branch protection rules to allow `No one` for push actions, i.e. any branch that matches the pattern, except for `main` or git tag patterns. https://docs.gitlab.com/ee/user/project/protected_branches.html#when-a-branch-matches-multiple-rules https://docs.gitlab.com/ee/user/project/protected_branches.h... > Gitlab enterprise has no mode of working that let's you have more than one active server at a time so goodbye horizontal scaling. Suggest reviewing the reference architectures documentation in https://docs.gitlab.com/ee/administration/reference_architectures/ https://docs.gitlab.com/ee/administration/reference_architec... to decide whether horizontal scaling is needed for your environment. For distributed environments, suggest looking into Geo: https://docs.gitlab.com/ee/administration/geo/index.html https://docs.gitlab.com/ee/administration/geo/index.html > You want to scale your cicd worker nodes? They want you to use docker mashine(a deprecated product) instead of writing a Plugin like ec2-fleet for Jenkins. The current GitLab CI/CD runner architecture involves docker-machine, based on a fork maintained by GitLab. This fork receives security and bug fixes to ensure users and customers can rely on auto-scaling in production. https://gitlab.com/gitlab-org/ci-cd/docker-machine#%EF%B8%8Fthis-is-a-fork-of-docker-machine- https://gitlab.com/gitlab-org/ci-cd/docker-machine#%EF%B8%8F... Please review the support statement in https://gitlab.com/groups/gitlab-org/-/epics/2502 https://gitlab.com/groups/gitlab-org/-/epics/2502 to learn more for how long the fork remains supported. The new auto-scaling architecture provides a task scheduler, and so-called fleeting plugins. You can review the architecture blueprint in https://docs.gitlab.com/ee/architecture/blueprints/runner_scaling/ https://docs.gitlab.com/ee/architecture/blueprints/runner_sc... and follow the documentation in https://docs.gitlab.com/runner/runner_autoscale/ https://docs.gitlab.com/runner/runner_autoscale/ If you prefer a timeline, please follow the Docker Machine Replacement Project Plan in https://gitlab.com/groups/gitlab-org/-/epics/6995 https://gitlab.com/groups/gitlab-org/-/epics/6995 For example, the AWS EC2 Fleeting plugin is available in Beta since GitLab 16.5 and scheduled for 16.7 GA, see the epic https://gitlab.com/groups/gitlab-org/-/epics/8856 https://gitlab.com/groups/gitlab-org/-/epics/8856 When using Kubernetes, you can take advantage of the Kubernetes executor to auto-scale pods. https://docs.gitlab.com/runner/executors/kubernetes.html https://docs.gitlab.com/runner/executors/kubernetes.html To optimize the CI/CD infrastructure next to auto-scaling, these tips might be handy, too: https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.... > into saas. Next to GitLab self-managed and SaaS, you can also use GitLab Dedicated, where you get access your own isolated cloud instance. https://about.gitlab.com/blog/2023/08/03/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated/ https://about.gitlab.com/blog/2023/08/03/building-gitlab-wit...
orf 3y ago
In what universe has Jenkins ever been described as “fine”?

thiht 3y ago

> Jenkins is fine for that As someone who managed hundreds of Jenkins instances from 2016 to 2018, Jenkins is now complete crap, stop using it. It was an ok product when the open source world offered no alternative but it's completely outdated compared to today's solutions. Deploying it sucks, its config as code format(s) are awful, the plugins are shit, upgrades can (and do) break everything, and I won't even saying anything about the design (not just the UI but also the UX and concepts). Jenkins is not fine for anything in 2023.

Roark66 3y ago
What alternative would you suggest? None of the large companies I worked at used anything other than Jenkins for cicd (well in one place we did use azure devops server - back then called teams If I remember correctly, but that was just for one app development team). Where they didn't use Jenkins they didn't have a dedicated cicd runner and they used github/gitlab instead. Both of these (although github less) suck for cicd IMO.
- thiht 3y ago
  Concourse, Drone, Gitlab CI all work fine. I've also heard of GoCD that looks interesting and looks like an actual "Jenkins successor" (more than an alternative IMO), but I've never used it.

dnsmichi 3y ago

Thanks for your feedback. GitLab team member here. > We(as in everyone) are in a serious need of a new git server product. Just do git serving, and do it well. Preferably in a way multiple nodes can be run active-active for scaling and reliability. No need for cicd (Jenkins is fine for that, thank you very much). You can integrate Jenkins into GitLab. https://docs.gitlab.com/ee/integration/jenkins.html https://docs.gitlab.com/ee/integration/jenkins.html Suggest considering a migration to GitLab CI/CD in your migration planning, following the updated documentation: https://docs.gitlab.com/ee/ci/migration/jenkins.html https://docs.gitlab.com/ee/ci/migration/jenkins.html and more automated imports in https://about.gitlab.com/blog/2023/09/26/atlassian-server-ending-move-to-a-single-devsecops-platform/#atlassian-server-end-of-life-migration-made-easy https://about.gitlab.com/blog/2023/09/26/atlassian-server-en... > Web hooks sending and receiving. For example launch a merge request webhook(to lambda via aws api gateway, or to Jenkins). Receive a webhook as merge request approval when some Jenkins job finishes. (FYI) https://docs.gitlab.com/ee/user/project/integrations/webhooks.html https://docs.gitlab.com/ee/user/project/integrations/webhook... and https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html https://docs.gitlab.com/ee/user/project/integrations/webhook... You can trigger a pipeline from external webhooks using a trigger token, and execute an action against the GitLab REST API. The example for triggering pipelines in https://docs.gitlab.com/ee/ci/triggers/#trigger-a-pipeline https://docs.gitlab.com/ee/ci/triggers/#trigger-a-pipeline can be expanded into more actions, i.e. using the API to create MR approvals or comments. For Python, I'd recommend looking into python-gitlab and this tutorial blog post: https://about.gitlab.com/blog/2023/02/01/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation/ https://about.gitlab.com/blog/2023/02/01/efficient-devsecops... > if you create cicd jobs/pipelines there is no way to giving someone an ability to run that pipeline without giving that person ability to push to the repository and submit merge requests. Yes, you can then set it so approval is needed before merge, protecting said pipeline, but why? There has been a ticket on gitlabs own issues page about it for years and it is still not resolved. Please share the URL :) When creating a new GitLab project, the default branch is protected by default, and only maintainer roles can push to the default branch. https://docs.gitlab.com/ee/user/project/protected_branches.html https://docs.gitlab.com/ee/user/project/protected_branches.h... A developer role can create non-protected Git branches, merge requests, and as such trigger a pipeline from a merge request. You've mentioned approval rules as a safeguard already - CODEOWNERS can be an additional way to ensure that review workflows are followed. https://docs.gitlab.com/ee/user/project/codeowners/ https://docs.gitlab.com/ee/user/project/codeowners/ You can also use branch protection rules to allow `No one` for push actions, i.e. any branch that matches the pattern, except for `main` or git tag patterns. https://docs.gitlab.com/ee/user/project/protected_branches.html#when-a-branch-matches-multiple-rules https://docs.gitlab.com/ee/user/project/protected_branches.h... > Gitlab enterprise has no mode of working that let's you have more than one active server at a time so goodbye horizontal scaling. Suggest reviewing the reference architectures documentation in https://docs.gitlab.com/ee/administration/reference_architectures/ https://docs.gitlab.com/ee/administration/reference_architec... to decide whether horizontal scaling is needed for your environment. For distributed environments, suggest looking into Geo: https://docs.gitlab.com/ee/administration/geo/index.html https://docs.gitlab.com/ee/administration/geo/index.html > You want to scale your cicd worker nodes? They want you to use docker mashine(a deprecated product) instead of writing a Plugin like ec2-fleet for Jenkins. The current GitLab CI/CD runner architecture involves docker-machine, based on a fork maintained by GitLab. This fork receives security and bug fixes to ensure users and customers can rely on auto-scaling in production. https://gitlab.com/gitlab-org/ci-cd/docker-machine#%EF%B8%8Fthis-is-a-fork-of-docker-machine- https://gitlab.com/gitlab-org/ci-cd/docker-machine#%EF%B8%8F... Please review the support statement in https://gitlab.com/groups/gitlab-org/-/epics/2502 https://gitlab.com/groups/gitlab-org/-/epics/2502 to learn more for how long the fork remains supported. The new auto-scaling architecture provides a task scheduler, and so-called fleeting plugins. You can review the architecture blueprint in https://docs.gitlab.com/ee/architecture/blueprints/runner_scaling/ https://docs.gitlab.com/ee/architecture/blueprints/runner_sc... and follow the documentation in https://docs.gitlab.com/runner/runner_autoscale/ https://docs.gitlab.com/runner/runner_autoscale/ If you prefer a timeline, please follow the Docker Machine Replacement Project Plan in https://gitlab.com/groups/gitlab-org/-/epics/6995 https://gitlab.com/groups/gitlab-org/-/epics/6995 For example, the AWS EC2 Fleeting plugin is available in Beta since GitLab 16.5 and scheduled for 16.7 GA, see the epic https://gitlab.com/groups/gitlab-org/-/epics/8856 https://gitlab.com/groups/gitlab-org/-/epics/8856 When using Kubernetes, you can take advantage of the Kubernetes executor to auto-scale pods. https://docs.gitlab.com/runner/executors/kubernetes.html https://docs.gitlab.com/runner/executors/kubernetes.html To optimize the CI/CD infrastructure next to auto-scaling, these tips might be handy, too: https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.... > into saas. Next to GitLab self-managed and SaaS, you can also use GitLab Dedicated, where you get access your own isolated cloud instance. https://about.gitlab.com/blog/2023/08/03/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated/ https://about.gitlab.com/blog/2023/08/03/building-gitlab-wit...

orf 3y ago

In what universe has Jenkins ever been described as “fine”?