111–120 of 121 posts
I'm really impressed by the hard work of GitLab team, keep it up! If anybody from GitLab is reading: any plans for rkt support?
Thanks! No current plans for rkt, but feel free to create an issue to discuss it.
Kind of unrelated, but I'm super happy to be working at GitLab. Nearly everything we do is out in the open, and most features are available in CE, which is fully open source ( https://gitlab.com/gitlab-org/gitlab-ce ). I've wanted great, open source tools that don't look like dung for a long long time, and GitLab is definitely reaching that goal. Can't help but gush about the product we're building. :D Here are some…
Sorry if this is the wrong venue to ask this, but any idea if/when Codeship will natively support you guys? It's honestly my one hangup since we do all of our deploys there.
Earlier quoted context omitted.
Sorry if this is the wrong venue to ask this, but any idea if/when Codeship will natively support you guys? It's honestly my one hangup since we do all of our deploys there.
Codeship founder here :) Getting a lot of requests for a GitLab integration recently and we're looking into it and are hopefully able to build it soon (I wish it would already be there)
Earlier quoted context omitted.
At my work, we have a setup close to this. On a successful build of jenkins (after build action), a deb is generated with FPM (awesome piece of software btw) and uploaded to an s3 bucket. Then on another machine, a cron that run every minutes sync the s3 bucket to a local aptly repository and publish it to another s3 bucket which is the real debian repository. This works well but the s3+cron part is probably not the…
I know it probably doesn't matter too much for internal use, but what does Lintian say about your packages?
Earlier quoted context omitted.
I know it probably doesn't matter too much for internal use, but what does Lintian say about your packages?
Many bad things! I didn't check until now but it's a bunch of "non-standard-dir-perm" and "dir-or-file-in-var-www" and things like "maintainer-name-missing". I think it's possible to build correct debian package with FPM but for our use, we just want to build easily native deb package.
Of course it is possible, it's just ridiculous amount of work. It's much easier to build package with proper tools in the first place.
These days it seems that Docker is everywhere. I am new to docker and I seem to find it as one more additional complicated system that the developer now needs to learn in order to deploy his or her application. How useful do you find docker for application which can be deployed on Heroku or Beanstalk? I can understand using docker for a Language ecosystem which is not supported on Public PaaS. Or for people for whom…
Contrary to your fears of everyone having to learn docker to develop, I see it as a tool that allows every developer on a team to be brought into new technology without having to learn all about a new toolchain. We are using docker-compose for this. Everyone has to install docker, and have some cursory knowledge of docker-compose commands, but that's it.
As an example, I recently shoehorned an angular2 front end into an existing project. Without docker, this means every developer needs node and all the dependencies before they begin to work. With docker-compose, the next time they start up the environment, the npm container installs all of their dependencies, and the typescript compiler container listens and compiles all changes to the webroot. The other developers don't even need to know what node is, or that it's being used!
Docker is a very powerful tool with a lot of untapped potential I'm sure. I've no experience with docker in production, however.
These days it seems that Docker is everywhere. I am new to docker and I seem to find it as one more additional complicated system that the developer now needs to learn in order to deploy his or her application. How useful do you find docker for application which can be deployed on Heroku or Beanstalk? I can understand using docker for a Language ecosystem which is not supported on Public PaaS. Or for people for whom…
Yes. The build scripts produce an image as well as a JAR.
It doesn't do anyone any good to have the knowledge of how to package your code for production locked in just a few people's heads.
Earlier quoted context omitted.
That's a pretty effective hiring method in my opinion. You guys should publish a blog post or something on your hiring practices and results - I'm sure the HN crowd would enjoy it.
Not to jump on to the gitlab bandwagon here. Adam from Skymind (YC W16) here I just want to say the last 4 hires we've made (we're only 11 soon 12) have been from around the world (we're in 4 countries) and this has worked great for us. A thriving open source community is key to hiring for us. A lot of our team does some sort of traveling. I myself will be working from tokyo (currently in korea actually..) moving fro…
Earlier quoted context omitted.
I'm running GitLab CE off a NAS to host my projects, and it works really well. Thank you all for making it freely available.
Glad to hear that, thanks for using GitLab! For other people, I think there are Synology packages on https://www.synology.com/en-us/dsm/app_packages/Docker-GitLa...
Earlier quoted context omitted.
Sorry if this is the wrong venue to ask this, but any idea if/when Codeship will natively support you guys? It's honestly my one hangup since we do all of our deploys there.
Codeship founder here :) Getting a lot of requests for a GitLab integration recently and we're looking into it and are hopefully able to build it soon (I wish it would already be there)
This has been a very standard response for the last 2 years.