Upgrade to Rails 5

Added ~122770 label

Here's a dump of the notes I've collected on Rails 5 so far (this is not comprehensive, etc.):

Helpful links:

Major breaking changes:

Access Control HTTP Headers - This deprecates config.static_cache_control in favor of config.public_file_server.headers, we use this in config/environments/production.rb.
HTTPS and config.force_ssl changes
before_filter and after_filter deprecated in favor of before_action and after_action.
assigns and assert_template have been separated out into the Rails Controller Testing gem.
Ruby 2.2.2 or above will be required. (!4948 (merged))
Rack 2.0 or above will be required.

Notable changes & New things:

Rails API
Action Cable
Snappier Development Mode in Rails 5 - with the listen gem Rails development mode will be made slightly faster for larger codebases.
New feature in Rails 5: Render views outside of actions - to render Rails views from background tasks and WebSocket workers.
Turbolinks jumps from 2 to 5 - Wouldn't recommend using this for a while, honestly. Not tested nearly enough so far and missing some basic functionality from Turbolinks "Classic".
Use kwargs in ActionController::TestCase and ActionDispatch::Integration HTTP methods - Any controller spec that uses get, post, delete, etc. with arguments will need to be changed to the format described in that PR. When we run the test suite on Rails 5 it'll throw deprecation warnings for this.
Rails 5 has added accessed_fields to find the fields that are actually being used in the application, useful for performance testing.

Changelogs:

Gems that will need upgrading (mostly comprehensive, not guaranteeing anything though):

Title changed from upgrade to rails 5 to Upgrade to rails 5

@jacobvosmaer have there been any updates on Ruby 2.2? It'll be required if we want to do Rails 5 support.

mentioned in merge request !3397 (merged)

mentioned in merge request !3398 (merged)

mentioned in merge request !3396 (merged)

mentioned in merge request !3400 (merged)

mentioned in merge request !3399 (merged)

mentioned in merge request !3409 (merged)

mentioned in commit 8edb3163

mentioned in commit f7a9fc9c

mentioned in commit db0da43a

mentioned in commit a6a7a5dd

mentioned in commit ccf50e81

@jschatz1 see the note above regarding jquery-scrollto-rails, looks like the gem is abandoned.

For anyone interested in upgrading to Rails 5:

I've updated my notes (see above) to be as comprehensive as I can assure. Should cover just about every gem (those explicitly mentioned in the Gemfile, at least) that needs updating, I think. I've opened issues or commented on existing issues for every gem that seemed stalled (I like pushing the ecosystem forward ). I've also updated gems that have made compatibility releases so far.

Now to wait for Rails 5 to actually be released...

mentioned in merge request !3434 (closed)

mentioned in commit 605eae85

@connorshea I don't know if we made progress on updating Ruby but I think @jameslopez is our expert on Ruby 2.2 compatibility. :)

I think we only need to fix https://gitlab.com/gitlab-org/gitlab-ce/issues/13514 so we can support Ruby 2.2. If Ruby 2.2.2 or above will be required. then we will have to completely drop support for Ruby 2.1.

@jacobvosmaer thanks!

@jameslopez has there been any progress in resolving that issue or finding a root cause so far?

I want to mention here that there is also the option, if I am not mistaken, of jumping straight to Ruby 2.3. If we are jumping anyway.

@connorshea I haven't had a chance to look into it. It's up for grabs, but I may be able to look at it if I have time after finishing off some priority issues.

@jacobvosmaer I think it's a good idea doing 2.3 soon as well. But not sure about ignoring 2.2... For instance Debian / Ubuntu do not use 2.3 by default in their stable releases (it could even be that they don't have the 2.3 option in their stable repo either), some people without the metrics enabled can also be currently running 2.2 without problems, some may be using the same Ruby version for other applications etc...

@jameslopez I agree it would be best if we fix the 'metrics crash rails console' bug. Telling people 'Ruby 2.2 works but sometimes segfaults' is not really an option I think.

@jameslopez https://packages.debian.org/jessie/ruby Looks like Ruby 2.1.5 is the default for Jessie, Stretch has 2.3.0 as default. Not sure how Debian's package manager works exactly, but I think that'd mean Debian allows installation of 2.3.0, it just doesn't come with it default? Correct me if I'm wrong.

@pravi what would happen if GitLab starts to require Ruby 2.3? Is that something your packaged version of GitLab could deal with?

Right now GitLab does not even support Ruby 2.2 but we have to keep up with Ruby on Rails.

@jacobvosmaer we are already using ruby 2.3 in unstable/testing, our main target for gitlab package. I have backported gitlab to stable, if required we can backport 2.3 to stable.

Thanks @pravi

@jameslopez it sounds more and more to me like we should skip Ruby 2.2 in favor of 2.3. And make sure the segfault goes away of course.

@jacobvosmaer I think that's fine as long as 2.2 works too...

@jameslopez but why bother with 2.2 at all?

@jacobvosmaer I must say I don't have a strong opinion on this, but see https://gitlab.com/gitlab-org/gitlab-ce/issues/14286#note_4589400 - In my opinion some people could be using it already or if they want to install Gitlab on premises, Ruby 2.3 may not the default Ruby in many distros? For instance, looks like Ruby 2.3 is not even available in any official stable release of Debian - only testing/unstable:

https://packages.debian.org/search?keywords=ruby2.3

Of course you can hack the sources.list but not sure about all the hassle for people who just want to install GitLab on premises...

See also the note about dropping support for Ruby 2.1 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2534#note_3388331 - Probably not many people are running on 2.3 yet.

Note for future, carrierwave may have issues with a Rails 5 change if we have any nested uploads in models: https://github.com/carrierwaveuploader/carrierwave/issues/1891

@jacobvosmaer we should probably have a ruby2.3 image for testing with GitLab's CI, then :)

Makes sense... Very easy to add but I guess we need to make sure everything passes or the build will keep bugging us. Relevant issue https://gitlab.com/gitlab-org/gitlab-ce/issues/12835

Ruby 2.3 may not the default Ruby in many distros? For instance, looks like Ruby 2.3 is not even available in any official stable release of Debian - only testing/unstable:

@jameslopez people have had to compile Ruby from source to run GitLab for many years now. Stable OS releases move at a completely different speed from the Ruby on Rails world. If we start walking in step with Debian we will fall behind Rails. I think pursuing apt-get install ruby is a mistake.

I think our goal should be to upgrade to a Ruby version that works with Rails and that does not crash when it runs GitLab. That would be either Ruby 2.2 or Ruby 2.3; not both because that creates a support burden for us.

cc @DouweM

@jacobvosmaer that's a fair point. As I said, I don't really have a strong opinion - just want to make sure we won't get many support tickets / requests if we only support 2.3 :)

@jacobvosmaer I agree. We shouldn't be blocked by stable distro releases. We can bundle in omnibus, and set requirements for source.

For Ruby 2.3: See also #12507 (closed), #12835 (closed).

mentioned in merge request !3643 (merged)

Gems which currently look to be abandoned and will need replacing:

quiet_assets, thankfully sprockets-rails has a PR open to add the functionality without an extra gem. (I'm not sure about what to do for this one, that PR hasn't been merged yet and Rails 5.0.0.rc1 is out)
jquery-scrollto-rails, last updated April 2014. (See #17166 (closed))
devise-async, a PR was opened in January, hasn't been merged or commented-on yet. (Devise Async can be replaced by a feature in Devise itself. Due to a bug we'll have to update to Devise 4.1.0 to use it, however)

mentioned in merge request !3645 (merged)

mentioned in commit 94b48d95

mentioned in commit 27e4dd38

mentioned in commit a7e1638b

mentioned in commit ca7fa510

mentioned in issue gitlab_git#20 (closed)

mentioned in issue #15575 (closed)

mentioned in merge request !3902 (merged)

mentioned in commit 88e4802d

mentioned in merge request !3644 (merged)

mentioned in commit 47698071

mentioned in issue #17166 (closed)

Rails 5 looks to be gearing up for a release candidate in the next few days (if not today!), so a lot of these gems will be updated with Rails 5 support next week :)

mentioned in issue #17145 (closed)

mentioned in merge request !4088 (merged)

mentioned in commit c24cd968

Milestone changed to Backlog

Removed ~122770 label

mentioned in merge request !4216 (merged)

mentioned in merge request !4238 (merged)

mentioned in commit ccafa785

mentioned in merge request !4295 (merged)

mentioned in commit 41624600

mentioned in issue #18049 (closed)

mentioned in merge request !4387 (merged)

mentioned in commit 09a80fee

Changed title: Upgrade to rails 5 → Upgrade to Rails 5

mentioned in issue #18077 (moved)

mentioned in commit 7d33fba7

mentioned in issue #18124 (closed)

mentioned in issue #3340 (closed)

mentioned in issue #13512 (moved)

http://weblog.rubyonrails.org/2016/6/30/Rails-5-0-final/

mentioned in merge request !5029 (merged)

mentioned in merge request !5030 (merged)

mentioned in merge request !5041 (merged)

mentioned in merge request !5042 (merged)

mentioned in merge request !5044 (merged)

mentioned in commit b37a8d8f

mentioned in merge request !5047 (merged)

mentioned in merge request !5051 (merged)

mentioned in commit d9edea97

Resources:

Removals/Changes worth caring about (for GitLab):

Removed deprecated only_path option on *_path helpers - I found quite a few uses of only_path in the app.
Removed deprecated deliver and deliver! methods. - Most of those were replaced, but there seem to be a handful left.
Files without a template handler in their extension will be rended using the raw handler instead of ERB. - could be a security concern if we have any views without extensions, worth checking to make sure.
skip_before_action, skip_after_action, and skip_around_action will raise an ArgumentError if the specified callback does not exist. - We do this a lot, apparently. If you get errors like Before process_action callback :require_no_authentication has not been defined, this is why.
ConnectionAdapters::Column::TRUE_VALUES was removed, this causes quite a few tests to fail.
Based on this commit from Shopify, one of the problems we run into is caused by a change that makes skipping verify_authenticity_token raise an error.

Deprecations worth caring about:

:controller and :action are deprecated for routes, we use them about 20 times in routes.rb.
assigns and assert_template have been extracted out into the rails-controller-testing gem.
Deprecated config.static_cache_control in favor of config.public_file_server.headers.
Deprecated config.serve_static_files in favor of config.public_file_server.enabled.
Deprecated alias_method_chain - This is going to be problematic for a lot of gems.
Deprecated use_transactional_fixtures in favor of use_transactional_tests for more clarity.
Deprecated uniq in favor of distinct.
Deprecated passing strings to the module builder, linked is the change needed for rack-cors
Deprecated Request.new(env) in favor of Request.new(request.env)
Deprecated redirect_to :back in favor of redirect_back, which accepts a required fallback_location argument, thus eliminating the possibility of a RedirectBackError. - We do this in one place.
render nothing: true is deprecated in favor of head :ok
#table_exists? currently checks both tables and views. This behavior is deprecated and will be changed with Rails 5.1 to only check tables. Use #data_source_exists? instead.

Other changes:

An application_record.rb file needs to be created.
An application_job.rb file needs to be created.
Replace all relevant rake commands with their rails equivalent.
Support for rails-deprecated_sanitizer has been dropped, it should be replaced with rails-html-sanitizer.

See the Rails 5.0 Release Notes for more information.

To find uses of methods that were removed or deprecated in 5.0, see the following (not comprehensive, see the pull request for all removals in Rails 5 as well as the release notes for all deprecations):

# Removed
git grep -c 'reset_changes'
git grep -c 'protected_attributes'
git grep -c 'assert_template'
git grep -c 'deep_munge'
git grep -c 'quietly'
git grep -cw 'capture'
git grep -c 'silence_stderr'
git grep -c 'silence_stream'
git grep -c 'RAILS_CACHE'
git grep -c 'use_route'
git grep -c 'only_path'
git grep -c 'to_ary'
git grep -c 'deep_munge'
git grep -c 'cached_attributes'
git grep -c 'cache_attributes'
git grep -c 'cache_attribute'
git grep -c 'parent_prefixes'
git grep -c 'source_macro'
git grep -c 'symbolized_base_class'
git grep -c 'encode_big_decimal_as_string'
git grep -c 'sanitize_sql_hash_for_conditions'

# Deprecated
git grep -c 'raise_in_transactional_callbacks'
git grep -c 'log_level'
git grep -c 'assert_tag'
git grep -c 'serialized_attributes'
git grep -c 'alias_method_chain'
git grep -c 'named_routes.helpers'
git grep -c 'serve_static_assets'
git grep -c 'static_cache_control'
git grep -c ':controller'
git grep -c ':action'
git grep -c 'before_filter'
git grep -c 'after_filter'
git grep -c 'around_filter'
git grep -c 'insert_sql'
git grep -c 'update_sql'
git grep -c 'delete_sql'
git grep -c 'use_transactional_fixtures'
git grep -c 'table_exists'
git grep -cw 'uniq'
git grep -cw 'deliver'

mentioned in commit f89a3349

mentioned in commit 62730e54

mentioned in merge request !5055 (merged)

RSpec 3.5 has been released!

mentioned in commit e09bdd78

mentioned in commit tnir/gitlab-ce@38533a2f

mentioned in commit cfb5a76b

Gems dropping support for anything below 2.2.2:

We can update the controller and request specs to get around this deprecation with the rails5-spec-converter gem, I tested and there are 93 files that need to be updated!

mentioned in merge request !5438 (merged)

mentioned in merge request !5439 (merged)

mentioned in merge request !5441 (merged)

mentioned in merge request !5442 (merged)

mentioned in merge request !5443 (merged)

@jacobvosmaer @connorshea we are planning to release rails 4.2.6 with next stable release of debian (stretch). It would be helpful if the last gitlab version with rails 4.2 is supported for security updates for a longer time.

Any scheduled plans to move to rails 5?
The same question about websockets.

@stanhu @DouweM could you comment on Praveen's request?

@pravi When did you expect to release Debian Stretch? Do you have a timeline in how long you would like to see Rails 4.2 support continue?

I don't think we've committed to a date for Rails 5 yet, but I could see this taking a few more months.

Ideally we'd be on Rails 5 by September or October, but we'll see.

Also @pravi as of 8.10 we're now on 4.2.7.

mentioned in merge request !5505 (merged)

mentioned in commit 0c799be6

mentioned in commit d7e3ecf4

mentioned in commit 0d022db5

mentioned in commit e9f5676a

mentioned in commit b8c78720

mentioned in commit 6985fea2

@stanhu https://release.debian.org/ lists key release dates as,

[2016-Nov-05] Transition freeze
[2016-Dec-05] Mandatory 10-day migrations
[2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day migrations)
[2017-Feb-05] Full freeze

We can't include new dependencies after Jan 5. If we can have the last gitlab release with rails 4.2 as an LTS release (only security fixes would be enough), that would be great. For newer versions we can use stretch-backports once stretch is released (hopefully 2-3 months from 2017 Feb 05). So at least 2017 May would be a good time for LTS support (the more it can extend, the better).

@pravi Thanks for the timeline. At this time, we can't commit to having a GitLab LTS version with Rails 4.2. We don't have a definitive timeline for the transition to Rails 5, but I think waiting until mid-2017 would be a bit too long to wait.

mentioned in merge request !5553 (merged)

mentioned in merge request !5555 (closed)

Paranoia is apparently running on 2.0 for 5 https://github.com/rubysherpas/paranoia/commit/a5b75b7454050e53af23342e721d7794cef46bd2

mentioned in commit a6ad88b8

Added ~480950 label

Are there any plans to migrate from unicorn to puma at the same time? See also https://github.com/rails/rails/pull/23906

@mrueg nope, not currently. Unicorn still works just fine.

Some other projects updating to Rails 5:

Note to self, test autoloading in production: https://twitter.com/benlovell/status/772841545439510528

Also be careful about lib being auto loaded, apparently? I really wish Rails had smaller, incremental releases instead of this mess.

@connorshea You need to only worry about autoloading in production if you have some code which is part of config.autoload_paths but not config.eager_load_paths. Check http://blog.bigbinary.com/2016/08/29/rails-5-disables-autoloading-after-booting-the-app-in-production.html

mentioned in issue #22082 (closed)

Mentioned in merge request !6349 (merged)

Mentioned in commit pfjason/gitlab-ce@7d33fba7

Mentioned in issue #5983 (closed)

@connorshea, acts-as-taggable-on 4.0.0 has been released.

@blackst0ne I'm aware :) See #22082 (closed)

@connorshea, oh, didn't see it.

Classes should inherit from ApplicationRecord rather than ActiveRecord::Base in Rails 5, see the BigBinary post on the topic.

I probably won't include that change in my initial Rails 5 MR since that's a pretty big change, I'll do it in a follow-up MR.

Mentioned in issue #22302 (closed)

Mentioned in commit b8c78720

Mentioned in commit 49405ac7

Some follow-up MRs I'd like to do:

Replace all uses of redirect_back_or_default with redirect_back, as is done here. I think this should be included in a separate MR.
Fix all the deprecation warnings for the Controller tests using this gem.
Fix all the deprecation warnings for uniq being replaced by distinct.
Classes should inherit from ApplicationRecord rather than ActiveRecord::Base in Rails 5, see the BigBinary post on the topic.
Fix all other deprecation warnings.
Figuring out a better fix for the Attempting to generate a URL from non-sanitized request parameters! An attacker can inject malicious data into the generated URL, such as changing the host. Whitelist and sanitize passed parameters to be secure. errors besides just setting config.action_controller.permit_all_parameters = true. See also https://github.com/rails/rails/issues/26289.

Mentioned in merge request !6461 (merged)

Mentioned in commit 570ae336

Mentioned in merge request !6660 (merged)

Mentioned in merge request !6661 (closed)

Mentioned in commit 8c280b1c

Mentioned in merge request !7291 (merged)

Mentioned in commit 87afcdff

There's currently an issue with elasticsearch-rails and Rails 5 that we may run into with EE: https://github.com/elastic/elasticsearch-rails/issues/608

mentioned in issue omnibus-gitlab#1762 (closed)

mentioned in merge request !7922 (merged)

mentioned in commit 9cbee6ec

mentioned in issue #26084 (moved)

Carrierwave 1.0.0 with rails 5 support was released on December 24, 2016.
https://github.com/carrierwaveuploader/carrierwave/blob/master/CHANGELOG.md#100---2016-12-24

@DouweM with Rails 5.1 being released I believe we should prioritize this

@dzaporozhets I agree.

/cc @mydigitalself

@DouweM what sort of size effort is this?

@mydigitalself Probably most of a month by one person.

changed milestone to %9.5

@mydigitalself we had tentatively planned https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183 for 9.4, but our current plan forward utilizes a feature of Rails 5.1.

I would prefer we stick with the officially supported secret protection in Rails, rather than use a third party service since we are close to 5.1.

This does mean that that issue would slip until we deliver 5.1 however.

mentioned in issue omnibus-gitlab#2183

@stanhu @smcgivern @DouweM I want to make this happen (one of my OKR) in Q3. I am willing to lead it but I need developer help here. I would like to have @vsizov full-time working on this starting from 8th of July. Can we make this happen?

@jschatz1 I probably need frontend developer help here if something got broken on FE side. Who can be my point of contact in case I need help? Someone who know both FE and a bit of Rails is preferable.

Thanks!

cc @connorshea ^

@dzaporozhets On the Platform side, @mydigitalself and I were looking at doing this in the 9.5/9.6 timeframe, which sounds like it would work with your planning. I think it would be more appropriate to put someone from Platform on this than from Discussion though, since the team has more people available, and this is not Discussion-specific. Does that work for you?

On the Platform side, @mydigitalself and I were looking at doing this in the 9.5/9.6 timeframe, which sounds like it would work with your planning

I think it would be more appropriate to put someone from Platform on this than from Discussion though, since the team has more people available, and this is not Discussion-specific. Does that work for you?

@DouweM if it's crucial for planning I am ok with a different candidate. Reasons why I chose @vsizov were next:

EU timezone.
He works in GitLab for a long time already so I expect wider knowledge of the code base.
He does CE to EE merges since forever which means he is used to fixing code and tests. And again should be good for general awareness of different code parts.
When I asked him if this is an interesting task he said yes.

@dzaporozhets just FYI, this can't be done without an update from the fog-google side of things, unless we were to remove the gem entirely.

See this PR: https://github.com/fog/fog-google/pull/210

@dzaporozhets I'm more than fine with @vsizov doing it, but I'm not sure if @smcgivern had him in mind for something else. Does reasons do make sense :)

@dzaporozhets This might be a big deal for FE. @lbennett should be able to handle this. Let's do it at least %9.5. %9.4 is completely packed and we are trying to clean up a lot of UI Polish bugs this month.

@jschatz1 sure, 9.5 is fine with me. thanks

just FYI, this can't be done without an update from the fog-google side of things, unless we were to remove the gem entirely.

@connorshea thanks. If this still be a blocker in a month - we just fork it and apply patch.

@dzaporozhets I think if the fog-google issue is blocking, we should help make it work since we can start on that now.

@victorwu can we schedule this for %9.5 ?

@jschatz1 : I think this falls to @mydigitalself to prioritize + schedule.

Sounds good to me!

@dzaporozhets @stanhu I have a contact at Google that works on open source projects relating to Google Cloud and he's worked on fog-google before, so he can possibly help out if needed.

@connorshea Great, put us in touch so we can work together on this.

@dzaporozhets I'm happy for @vsizov to take this, but I may need to borrow someone from @DouweM's team for 9.5. @DouweM and I can handle that with the relevant PMs, though - this is just FYI

@smcgivern thanks

@vsizov please ping me when you ready to start working on this

FYI there are new useful resources out there:

assigned to @dzaporozhets and @vsizov

MR https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12841

changed the description

mentioned in merge request !12841

mentioned in merge request !12992 (merged)

marked this issue as related to #35376 (moved)

mentioned in merge request !13040 (merged)

The previous week I was busy with other tasks, this week I'm fix4all.

The fix4all is ended but I still have some issues to work on apart of the rails 5 upgrade. If nothing changes, I will be back on Wed

@DouweM can we have an extra person to help here? It seems @vsizov is busy with many other things besides working on this issue. cc @smcgivern

@dzaporozhets Everyone on my team is already working on their own %10.0 tasks as well... I may have 1 or 2 (partially) available next week if their other assignments end up taking less time than expected, but not for at least a few days.

changed milestone to %10.0

@DouweM yes, I believe we have more important things for 10.0. But if you have someone unassigned before or after 10.0 - we will use extra help here.

mentioned in issue #36552

marked this issue as related to #36552

@dzaporozhets I may have @oswaldo or @felipe_artur available either this week or next week, but neither as full-time. Sorry for stealing @vsizov back for so long

If either Felipe or Oswaldo can help, are there any specific things they should look at, or should they just dive into the failures on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12841?

@smcgivern I'd have today and the next two days of this week to help on this and continue on my %10.0 deliverable. I'll be off next week.

Either way, I'd be happy to make at least a few contributions here.

@oswaldo ah right, I forgot about that Please keep working on your other deliverable until you're blocked, then take a look at this if you have any free time.

changed the description

@smcgivern thanks!

@DouweM @vsizov @smcgivern I don't think this one is making 10.0. I will be off next week so can't work on it. Merging something like this close to RC is risky. So I propose we target to 10.1 for https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12841 (Rails 5.0) and 10.2 for Rails 5.1 update

@dzaporozhets sounds sensible to me

changed milestone to %10.1

added In dev label

It seems like we break Rails 5 compatibility in CE master faster than I fix it in rails5 branch. That means that "complete state" may never happen. Maybe this is a wrong impression due to my vacation and other tasks but still... any help is appreciated.

@vsizov how can I help you?

@vsizov @dzaporozhets what should we do about this?

Right now I'm resolving conflicts after pulling the master so we need to wait until the new failures are coming up but these ones (https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/29879651 and https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/29879668) can be already taken by someone else.

Is it possible that we make a job that would try to integrate Rails 5, and make it allowed to fail and people would be aware what could break in Rails 5? I feel this is similar to CE to EE, people just need to be aware otherwise we're never going to catch up.

@godfat CE to EE happens regularly, has 5 people doing daily merges and is requires for GitLab to be released. So besides being aware, people also solve problems. Rails 5 is not blocking anything neither have enough manpower to be more than "concern".

So by adding rails 5 CI job that will always fail we won't move much forward

@godfat That possible but I'm not sure it is worth to do that. Before my vacation, it didn't look that bad, the main problem is that we dedicated ~0.7-0.8 of full-time working developers on this but we need (initially planned) 1.5 full-time working developers. It's my subjective take on this.

@smcgivern its question of capacity. We either throw 3 devs full time on that and make it in one month or it never happens.

mentioned in issue #37723

marked this issue as related to #37723

marked this issue as related to omnibus-gitlab#2183

@dzaporozhets sorry, I was away. I take it we still need more people on this?

@smcgivern I talked with @sytses and we agreed it better to be done quickly (in a month) by assigning several people to it. However, we don't want to hurt Q4 roadmap. So we can delay it up to Q1 2018. I leave it up to you and @DouweM to decide how to proceed with it based on resources you have. OK?

@dzaporozhets I'd really hate to leave it that long, because there's an MR already making good progress.

Next release (10.2) we have our summit, but I think @DouweM and I should each be able to provide one person to help with this for the 10.3 release. We have some new team members joining (or already joined in the case of @mbergeron), so that will help with capacity.

/cc @mydigitalself @victorwu

changed the description

@dzaporozhets @vsizov I'm moving this to 10.3 for that reason, and I will try to have Valery + another developer work on this in 10.3, with one more from Douwe's team.

changed milestone to %10.3

added Discussion label

@smcgivern perfect, thanks. I unassign myself from it for now

unassigned @dzaporozhets

mentioned in issue #31847 (moved)

moved to gitlab#4480

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

Upgrade to Rails 5

TODO:

Benefits

Designs

Child items ...

Activity

Frequently Asked Questions

Admin message

Admin message

Upgrade to Rails 5

TODO:

Benefits

Relates to

Activity

Frequently Asked Questions