Can merge branch before build is started

@tkuczma Please could you provide some more information about the environment where you have noticed the problem:

Please mention if you are seeing the issue on GitLab.com. If seeing the issue on your own hosted GitLab instance, please provide the following information:

Run a diagnostic check of GitLab and it's components:

sudo gitlab-rake gitlab:check

Gather GitLab specific environment information:

sudo gitlab-rake gitlab:env:info

added ~19173 ~65372 external services ~13921 labels

@markglenfletcher here it is, URLs were anonimized


System information
System:		
Current User:	git
Using RVM:	no
Ruby Version:	2.3.3p222
Gem Version:	2.6.6
Bundler Version:1.13.7
Rake Version:	10.5.0
Sidekiq Version:4.2.7

GitLab information
Version:	8.16.4-ee
Revision:	93daa28
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	9.2.18
URL:		https://git.acme-internal.com
HTTP Clone URL:	https://git.acme-internal.com/some-group/some-project.git
SSH Clone URL:	git@git.acme-internal.com:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	yes
Using Omniauth:	no

GitLab Shell
Version:	4.1.1
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
Hooks:		/opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:		/opt/gitlab/embedded/bin/git

added ~1071781 ~113220 labels

ZD ticket #66592

@godfat Are you aware of this one?

@markglenfletcher are you still awaiting feedback from us? I think we sent all you've asked for.

Do you have some hints as to what might have happened? It might be better to try and check the logs before they rotate into oblivion

removed ~65372 label

@markglenfletcher Yes, I cannot say this is intentional, but according to the code, this is expected.

Here we could see that if there's no pipelines at all, it would give true.

def mergeable_ci_state?
  return true unless project.only_allow_merge_if_build_succeeds?

  !head_pipeline || head_pipeline.success? || head_pipeline.skipped?
end

Not sure if changing it to strictly require a pipeline would break anything. Perhaps we could try.

mentioned in merge request !9627 (closed)

I created !9627 (closed) and let's see how it goes.

So the only failure was: https://gitlab.com/gitlab-org/gitlab-ce/builds/11385053 It was a unit test which specifically test that without having a pipeline it should be mergable:

  1) MergeRequest#mergeable_ci_state? when it is only allowed to merge when build is green when no pipeline is associated should be truthy
     Failure/Error: it { expect(subject.mergeable_ci_state?).to be_truthy }

       expected: truthy value
            got: nil
     # ./spec/models/merge_request_spec.rb:968:in `block (5 levels) in <top (required)>'

This means it is intentional, but there might not have a strong reason behind it because there's no feature test for this.

@ayufan @markpundsack Does it make sense if Only allow merge requests to be merged if the build succeeds is on, we don't allow it to be merged when there's no pipelines at all? The only issue I could foresee is this would break having [ci skip] in the last commit. Previously it would allow it to be merged, but not when we strictly require a head pipeline.

It's fine to me though. I sometimes would also ask people don't use [ci skip] for documentation changes because we still want to see at least one test passed.

I'd think [ci skip] should mean treat it as success and let the MR be merged. If you know a change you made has zero impact on any tests (say a readme change), it's silly to enforce a useless pipeline.

But, to the meat of the question, are there other times when someone would have that option enabled (Only allow merge requests to be merged if the build succeeds) but have no pipelines? e.g. they don't have GitLab CI or other services configured, but the option was enabled by default somehow? Or they have CI, but only for certain branches, and so sometimes there won't be one?

Not really sure. It seems like a relatively safe change (modulo the [ci skip] concern above), but I am not sure I'm aware of all the edge cases.

Umm.... good points. Now I am not sure if it would be a safe change. It could also break a lot of people's workflows, forcing them to disable this.

Can you give us an estimation for when this issue will be fixed? This bug is quite frequently causing developers to mistakenly merge requests that haven't been built yet.

@jbochenski Sorry that we don't have an estimation for this because before we figure out how we could do this without breaking other people's workflow, we cannot just change it. I'll label this as a feature proposal for now because it would be a breaking change or a whole new feature unless we could find some way around it.

added feature proposal label

I think that the problem here is that "we may need another option", as we don't really know when there's an external integration. So probably having something like:

- Only allow merge requests to be merged if there's pipeline

Would allow us to prevent that as system will wait for Pipeline, and Pipeline that is green.

@godfat The option is called Only allow merge requests to be merged if the build succeeds, what you are telling us it that it's really Only allow merge requests to be merged if the build didn't fail

While I understand some people might be relying on the current behavior, it is clearly not working as advertised. This issue has been open since February with no real work done. Can we please get this fixed already?

If you think a new option is needed that's fine. For us it's still a bug, however you spin it. We just want the developers to be sure their feature branch has been successfully built when they click the "Merge" button.

@mydigitalself This is a support scheduling request. We'd like to get this issue prioritized.

@bikebilly Can you decide on that? This seems to be mostly ~CI stuff, maybe Platform stuff.

changed milestone to %Backlog

added SP1 and removed SP2 labels

mentioned in issue #33663 (moved)

changed title from Can merge branch before Jenkins build is started to Can merge branch before build is started

changed the description

moved to gitlab#8494

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Can merge branch before build is started

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Designs

Child items ...

Activity

Frequently Asked Questions

Admin message

Admin message

Can merge branch before build is started

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Activity

Frequently Asked Questions