Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab 8.9 released

about.gitlab.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: GitLab 8.9 released

#51

Post by sytse »

nisa wrote: post #48
sytse wrote: post #47

Earlier quoted context omitted.

Thanks for your kind words Nina. I'm glad you appreciate the openness, effort, education pricing and packaging. The wiki is something we don't but enough effort in ourselves, it is not Gollum's fault. There are a lot of open issues for it https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&sor... We've been using static websites a lot ourselves instead of wiki's pages.gitlab.io I would love for people to contrib…

> We've been using static websites a lot ourselves instead of wiki's pages.gitlab.io Sure I can understand that it's not a priority but I don't think wiki and static pages have to exclusive - we have a lot of non-technical users and e.g. pushing a static version of the wiki to gitlab pages would ease creation of documentation, so users can use the editor and markdown and the preview to write the wiki and everything g…

I agree that wiki's have their place and a valuable. Just wanted to explain where our efforts have been. Thanks for looking into contributing https://about.gitlab.com/2016/06/16/fearless-contribution-a-...

Re: GitLab 8.9 released

#52

Post by sytse »

ech wrote: post #49
superuser2 wrote: post #46

Earlier quoted context omitted.

>merge restriction as a feature Ability to enforce code review (allow users to approve merge requests but not push directly) has been demanded since 2014 [1] with no support from Gitlab. However, it looks like there's now a chance it's coming soon. [2] [1] https://github.com/gitlabhq/gitlabhq/issues/6432 [2] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals. it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.

Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?

Re: GitLab 8.9 released

#53

Post by superuser2 »

sytse wrote: post #52
ech wrote: post #49

Earlier quoted context omitted.

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals. it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.

Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?

This is nice, but does not solve the problem of giving a user the power to approve merge requests but not accidentally "git push origin master."

Re: GitLab 8.9 released

#54

Post by ech »

sytse wrote: post #52
ech wrote: post #49

Earlier quoted context omitted.

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals. it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.

Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?

i am, i get people to use it, and it works well. but superuser2 is right. to be honest, i think we're touching to fundamental limitations in the git model that gitlab cannot solve without becoming rational team concert, and catering to a fundamentally different public.

Re: GitLab 8.9 released

#55

Post by bigdrum »

My most wanted feature is manually (from a gitlab ui, not api) triggered build for deployment. Is it just me, or am i missing some good practice that people can live without it?

Re: GitLab 8.9 released

#56

Post by mikewhy »

intsunny wrote: post #4

Will repo deploy tokens ever be a thing? I would like read-only deploy tokens associated to a repo, and not a user. I just don't like having to create dummy users with repo access to generate deploy tokens.

The CI token for a project allows the runner to fetch a repo with basic auth. Would that work?

Re: GitLab 8.9 released

#57

Post by sytse »

superuser2 wrote: post #53
sytse wrote: post #52

Earlier quoted context omitted.

Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?

This is nice, but does not solve the problem of giving a user the power to approve merge requests but not accidentally "git push origin master."

With protected branches you can prevent force pushes to master. You would have to do a manual merge and then git push origin master to cause a problem I think.

Re: GitLab 8.9 released

#58

Post by grzesiekb »

bigdrum wrote: post #55

My most wanted feature is manually (from a gitlab ui, not api) triggered build for deployment. Is it just me, or am i missing some good practice that people can live without it?

Recently we added a feature that makes it possible to trigger a new pipeline from UI. It can solve your problem. We are also working on extending our support for environments, so if you need a more flexible solution, stay tuned!

Re: GitLab 8.9 released

#59

Post by MandieD »

I discovered GitLab on Azure Marketplace (of all places...) and have fallen in love with it for managing PowerShell and other Windows automation projects done in Visual Studio Code (of all things...). To really use it though, I have to get it installed on-prem, and our Unix server guys do not like the default user and group names they saw on the VM: they insist that they have to be max eight characters, no dashes. I'm not going to argue that it's sensible, just that it is :)

It looks like I can use the manual install process - any of you guys done that lately, using user/group names different from the defaults?

Also, they want the stuff installed on an NFS share, not the OS partition. Reasonable, or unreasonable for GitLab?

Re: GitLab 8.9 released

#60

Post by dblessing »

MandieD wrote: post #59

I discovered GitLab on Azure Marketplace (of all places...) and have fallen in love with it for managing PowerShell and other Windows automation projects done in Visual Studio Code (of all things...). To really use it though, I have to get it installed on-prem, and our Unix server guys do not like the default user and group names they saw on the VM: they insist that they have to be max eight characters, no dashes. I'…

I'm glad you love using GitLab to manage your automation projects. Luckily, you can still use the Omnibus install but change the default usernames :) In `/etc/gitlab/gitlab.rb` we have the following configuration options:

registry['username'] = "registry" registry['group'] = "registry" user['username'] = "git" user['group'] = "git" postgresql['username'] = "gitlab-psql" redis['username'] = "gitlab-redis" web_server['username'] = 'gitlab-www' web_server['group'] = 'gitlab-www' mattermost['username'] = 'mattermost' mattermost['group'] = 'mattermost'

Change these to acceptable values and it should work well for you. If there are any other blockers in the Omnibus package, please create an issue at https://gitlab.com/gitlab-org/omnibus-gitlab/issues and we'll do our best to accommodate them.

Post reply on HN