Make it easier to write specs for LDAP-enabled states
There have been a few regressions introduced as part of the Login UX upgrade that only occur in LDAP-enabled environments (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7274 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6993 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7058).
When I was working on that feature, I did some manual testing by reconfiguring and restarting my local GitLab instance. But testing each change across multiple configurations (signup, crowd, and/or signin enabled/disabled) was virtually impossible. The best I could do was temporarily change certain flags in the UI to force certain components to render.
In working on some of the regressions, I have attempted to write tests to cover LDAP-enabled states, but even with help from other devs I haven't been able to get them working.
It seems to me that we should provide a clearer path for writing automated tests for variously configured instances of GitLab. At this point, it seems that many configurations are untested and perhaps untestable.
I'm out of my depth here, so I have no idea what would be involved in fixing this, and/or it's possible that I'm missing a very simple solution. If someone can provide insight on how this can be done already, perhaps we just need to provide better documentation.
Activity
@brycepj Instead of
allow(Gitlab.config.ldap).to receive(:enabled).and_return(true) allow(Gitlab::LDAP::Config).to receive(:servers).and_return(@ldap_servers)try:
allow(Gitlab::LDAP::Config).to receive_messages(enabled?: true, servers: @ldap_servers)I agree that this is hard to test for views. There are pretty good helpers for testing backend specs now (
LdapHelpers), but it really assumes that you're relying onGitlab::LDAP::Configfor configuration. Some places pullGitlab.config.ldap, as you've seen. I haven't done enough writing tests for frontend stuff so I am not exactly sure how to make this better.
Edited by Bryce JohnsonMentioned in merge request !7274 (merged)
mentioned in merge request !8730 (merged)
Hi,
First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time. To establish order in the GitLab-CE Issue Tracker, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria:
- No activity in the past 12 months
- No milestone (unscheduled)
We'd like to ask you to help us out and determine whether this issue should be reopened.
If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.
If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks for your help
added auto updated awaiting feedback labels
removed auto updated awaiting feedback labels
added Manage [DEPRECATED] label and removed 1 deleted label
added devopsfoundations label
added [deprecated] Accepting merge requests label
removed [deprecated] Accepting merge requests label
-
Hey!
👋 GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.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/13855You 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/13855What 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 theee/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/13304Will 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.
