3 ms·
We don't like plugins because they are a bad user experience, make it hard to upgrade, and make it hard to improve the product. We rather see people contribute
by sytse 10y ago
We don't like plugins because they are a bad user experience, make it hard to upgrade, and make it hard to improve the product. We rather see people contribute features to GitLab itself including tests. This way we can make sure they are nicely integrated in the UI and that they still work when we release a new version of GitLab. This allows users to upgrade with confidence and it allows us to make major changes to GitLab.
I'm not sure what you use case it but GitLab CI is pretty extensive and I hope it has everything you need. Please let me know if there is anything missing. If you want to host your code somewhere else you can still use remote mirroring to have GitLab do the deploy.
The GitLab Runner is a simple piece of software on purpose. This allows us to port it to many platforms. All the logic is in GitLab itself so it is easy to provide a lot of feedback about the status in the UI.
- scrollaway 10y agoThe problem with Gitlab CI, last I looked at it, was the inability to untie it from gitlab and run+self host it standalone. Has this changed?
- sytse 10y agoThe only way to use GitLab CI is as part of GitLab. By doing this we could deeply integrate it into the interface of GitLab and make it a better user experience. If you host your code anywhere else you can use remote mirroring (EE/.com only) to use GitLab CI.
- scrollaway 10y agoYou can't make it replace Jenkins if it can't do arbitrary jobs. I'm talking jobs without even a repository behind them. The idea of a runner that tests every commit on a repo is super useful. But Jenkins goes one step further by being essentially an arbitrary shell command runner. I use it for example as a CNC for running cleanup jobs, cronjobs etc.
- sytse 10y agoMaybe the repository can contain the code of the cleanup jobs?
- scrollaway 10y agoThis is shoehorning something into a model that doesn't fit it :/ For example, on Jenkins right now, we have a job which can trigger a bunch of load tests against our website. We can run this job indefinitely, give it arguments, it'll even run a local web server. By default, the job only runs the load test for ~10 mins. The job is run periodically. When it fails, we get emails. After it completes, regardless of failure, it triggers a "cleanup" job which deletes the loadtest-related data from the website. This is what I mean with "arbitrary jobs". I think it's absolutely fair to consider them out of scope, but if you want to replace Jenkins, this is what you're going up against.
- sytse 10y agoThanks for sharing your use case. I think that code of the cleanup job can be in the same repo as the load test itself. Would that be a fit for you? Of course the load test code can have the testing code of the application as a dependency. Maybe you prefer the load testing code in the same repo as the application. In that case it should be two jobs that are triggered periodically I think. I think what GitLab CI still needs is periodic jobs https://gitlab.com/gitlab-org/gitlab-ce/issues/2989 https://gitlab.com/gitlab-org/gitlab-ce/issues/2989 (right now the workaround is sending a build trigger for an external task).
- aalbertson 10y agono, it does not fit the bill. It needs truly arbitrary job running. I want to be able to just drop in some arbitrary command (e.g. df -h /some/build/agent/dir/ | grep 99%) that would not be worth it to me to write a script, commit it to git, get that deployed and running. In fact, I AM a fan of this being in git, but the example I'd use is an improvement on TeamCity, where you can configure your job and project configurations to "commit to git" so that you can easily restore when you need to rebuild a server or reload a previous version. Sooooo many use cases for arbitrary jobs. Many of which may be short lived, but want them automated in some way. (speaking as a sysadmin/eng/devops/cloud dude)
- avtar 10y agoI would love it if Gitlab CI went back to being a separate product. I'll use Gitlab for my own projects but ones that I work on with others are challenging to migrate. And creating mirrors on Gitlab of repositories hosted elsewhere to make use of CI/CD features doesn't sound ideal.
- sytse 10y agoI agree it is not ideal but it should work pretty smoothly, have you tried https://docs.gitlab.com/ee/workflow/repository_mirroring.html https://docs.gitlab.com/ee/workflow/repository_mirroring.htm... ?
- avtar 10y agoI understand why your different offerings are bundled together, I appreciate how your team tends to reach out to users in public forums such as this one, and I'm a fan of the quality of your work, but quoting from the page you linked to: "any commits should be pushed to the upstream repository, and will end up in the GitLab repository automatically within an hour, or when a forced update is initiated." "Wait up to an hour for things to happen" isn't a great story to pitch to team members :/ I'm also talking about at least twenty different repositories. I'll most likely have to continue using Jenkins for those projects but I look forward to using Gitlab CI on weekends.