Live data from Hacker News

Moving to GitLab: Yes, it's worth it

about.gitlab.com

341–350 of 356 posts

Re: Moving to GitLab: Yes, it's worth it

#341

Interesting. For projects that don't need a "community" we've been using Amazon CodeCommit. We don't like to use Github anymore because of the politics there. Example: We had a project involving software filters that included this sentence in the description: > Phase is related to time, but a pure time delay does not involve any phase shift. A pure time delay or "group delay" is constant with frequency. Phase shift v…

We removed our project and never used github again. That seems like a totally disproportionate approach versus responding with a polite 'this is a legitimate use of the word, thanks' message.

Typically US, blocking the use of such words. Everybody says 'fuck' in the US, constantly, but whey you use it on TV or post it online, all hell breaks loose. It's just a word folks, get over it. What is the worst that could happen when you see 'fuck' or 'retard' somewhere?

I'm also curious on how many downvotes I will get for this, because the polite way is to use f*ck or something, right?

Re: Moving to GitLab: Yes, it's worth it

#342

I would like to see that there is just one gitlab version, and that the enterprise features are simply available in the community edition too. I will not pay just for a feature like repo mirroring, but it's i think a feature many people will use and or utilise when moving, migrating to a gitlab setup. But it is the one and only feature i am missing so not worth upgrading to EE for me. As soon as an alternative (open…

If you think about what you're asking: youre asking for folks who build infrastructure you rely on to have no viable way of creating a self sustaining business model. Aka no virtuous circle. No development. This perspective is a classic tragedy of the commons situation and makes perfect sense for you to have as an individual. But it's sad.

There will always be users like me who know how to self host stuff and don't want 3rd parties having access to their repos. But there will always be plenty of people who like to outsource this, have it hosted by 3rd party etc etc. It's the service that is worth the money, not the features.

Features have a limited value, they are valuable until an alternative provides it for free (which is the common thing these days). And that will happen here too, just take times. Same as gitlab nibbled at github, something else will come around to take share from gitlab.

Simplifying the development to just one tree/version, saves a lot of maintenance, development discussions, allows feedbacks of all features by self hosting users as if they were enterprise hosted clients. This also has a value.

Re: Moving to GitLab: Yes, it's worth it

#343

I would like to see that there is just one gitlab version, and that the enterprise features are simply available in the community edition too. I will not pay just for a feature like repo mirroring, but it's i think a feature many people will use and or utilise when moving, migrating to a gitlab setup. But it is the one and only feature i am missing so not worth upgrading to EE for me. As soon as an alternative (open…

We do our best to make CE and EE excellent, where the features that land in EE are mostly interesting for larger teams. For every feature that we don't bring to CE, this is always a hard decision. We wrote about this here: https://about.gitlab.com/2016/01/11/being-a-good-open-source...

Hoi Job :) mogguh

I understand, and money has to be made too. It's a nasty trade off. Though as i wrote to the other reply, its the service that is worth the money not necessarily the feature(s).

IMHO, there is always a certain percentage of users that want to pay. The more users in total, the larger the amount of paying customers.

And the repo mirroring would be a great feature to let me move a lot of github project users to gitlab without losing any potential updates from an upstream source.

It would also allow for nice backup purposes, though you could do that now of course already with the hosted enterprise solution. But if the feature was in CE, many would be used, familiarised, to the feature, and perhaps see the added value of a backup node ($$) at gitlab.

Re: Moving to GitLab: Yes, it's worth it

#344
post #114

Earlier quoted context omitted.

I couldn't help noticing Gogs is hosted on GitHub... https://github.com/gogits/gogs

GitLab also started out on GitHub didn't it?

Yes we did. And we still have a non-canonical mirror there https://github.com/gitlabhq/gitlabhq#canonical-source

I totally understand why people host open source projects on GitHub.com, most open source developers have accounts there so it lowers the barrier to contributing.

BTW If you host it on GitLab.com people can login with their GitHub account.

Re: Moving to GitLab: Yes, it's worth it

#345

Earlier quoted context omitted.

We're working hard on making CI super easy to use and setup. If you want to give it a spin, check out our recent blog post on starting from 0: https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/

I was trying to look into Gitlab Runner the other day. How decoupled is it from Gitlab itself? Would I be able to somewhat easily write a completely different UI, with a different framework/language (say, Django), hook it all up to Github/Gogs and use Gitlab runner for the jobs themselves? Because if that's what it is, that is pretty kickass.

The Runner interfaces with GitLab through a pretty simple API, so you could do that.

One caveat is that we might introduce a new API by releasing a new version of GitLab and GitLab Runner at the same time, then you would need to upgrade you project to stay compatible.

BTW To ensure nobody is confused, you can use GitLab Runner to test all kinds of projects on all kinds of hardware. We're discussing developing an alternative to GitLab but reusing GitLab Runner.

Re: Moving to GitLab: Yes, it's worth it

#346
post #230
post #205

Earlier quoted context omitted.

That is a different case than configuring a different remote on config and pushing to another host which is what I interpreted reading your comment, my bad. Out of curiosity, does the import process include all issues, PR and comments?

almost, yes. issues, wiki, PRs and comments are imported. Afaik cross repo PRs are not supported yet. But they're working on that. :)

For sure, progress on that is in https://gitlab.com/gitlab-org/gitlab-ce/issues/15528

(BTW labels are also imported)

Re: Moving to GitLab: Yes, it's worth it

#347

Their UI is too slow (as many other Ruby web apps).

If you're talking about GitLab.com, this is due to other issue https://gitlab.com/gitlab-com/infrastructure/issues/59

If you're talking about a self hosted instance, we think it is OK right now and frontend code will get better now that we adopted https://vuejs.org/

Re: Moving to GitLab: Yes, it's worth it

#349

Earlier quoted context omitted.

Heroku offers automatic deploy on linked repos from GitHub. Do you plan to integrate with Heroku to offer similar feature?

I believe the ball lays with Heroku for this one, mostly, but we'd love to see that in GitLab of course. However, you can already deploy from GitLab quite easily to Heroku, it just requires a single line in your CI config: http://docs.gitlab.com/ce/ci/examples/test-and-deploy-ruby-a...

And with Heroku's beta support for Docker deployments, it's even easier.

Re: Moving to GitLab: Yes, it's worth it

#350
post #322
post #252

Earlier quoted context omitted.

Im using Jenkins right now to basically handle docker deployments. Without taking the time to actually read up on it in depth, does GitLab CI handle ways for me to essentially just pull prebuilt images and run them on a targeted server with desired settings? I'm already preparing to move to GitLab CI for images that I build myself (since Im already storing the Dockerfiles on gitlab)

Yes, using prebuilt images is easy. Basically, just add `image: ruby:2.3.1-alpine` to a job, for example. Docs: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html...

That seems to be referring to using docker images as part of the build process.

Im referring to using docker images as the deliverable. I mostly want to just have a gui to do "docker pull x" "docker stop xcon && docker rm xcon" "docker run --name xcon -v /volumes/x/config:/var/www/config -p 8080:80 x" for me. There would technically be nothing to be stored in the gitlab repo here, except the config.

Replace the "docker pull x" step with docker build in the event that I'm using a dockerfile to build a custom image, which could trigger as a result of updating the dockerfile... but usually the dockerfile doesnt change, it just needs to be re-run to pull in upstream changes.

Post reply on HN