Prior to this commit, we had a single test for `FeatureFlag.enabled?`,
namely that it delegates to `Flipper.enabled?`. This commit adds some
tests to both verify behavior and communicate to developers the
intentions of the related methods:
- `FeatureFlag.enabled?`
- `FeatureFlag.accessible?`
My hope is the documentation and tests will help address the horrors
mentioned in conversation in #16416:
> I have lived the horrors of having a feature flag accidently
> flipped or incorrectly setup in the first place and half baked
> functionality going live.
Note: I'm not proposing that we test other `Flipper` methods, but
instead to ensure that we're testing and documenting the behavior of
what I believe to be the two primary mechanisms of "putting something
behind a feature flag."
Related to #16406, #16416
* Short-circuiting parsing any articles to update
Setting a field that is to help track from where we received an image.
Related to #16075 and #16407.
See [Slack Thread][1] for all the details
[1]:https://forem-team.slack.com/archives/CSY5KKK9U/p1643916711077719
* Fix
* Apply suggestions from code review
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
This commit builds on the conditional rendering of navigation links by
adding a routing constraint to all :listing routes.
The impact is, if we were to disable the listing feature (e.g.,
`FeatureFlag.disable(:listing_feature_enabled)`) all requests to `GET
/listings` (and those drawn in the [config/routes/listings.rb][1] file)
would return a 404 response.
Related to forem/rfcs#291, #16335, #16338, #16362.
Testing this change:
1. Start your local application (e.g. `$ bin/startup`)
2. Go to http://localhost:3000/listings
3. You should get a Successful response.
4. Now disable the feature (e.g. `$ bin/rails r \
"FeatureFlag.disable(:listing_feature_enabled)"`)
5. Refresh http://localhost:3000/listings
6. You should get an `ActiveRecord::RecordNotFound` error; because the
application is now looking for a user or org named "listings"; in other
words we're not routing `GET "/listings"` to `listings#index` controller
action.
7. Now enable the feature (e.g. `$ bin/rails r \
"FeatureFlag.enable(:listing_feature_enabled)"`)
8. Refresh http://localhost:3000/listings
9. You should get a Successful response.
10. Goto 4
This commit is intended to be the penultimate change before we toggle
the listings section off by default.
[1]:c2ce2c32d5/config/routes/listing.rb (L1)
This passed in the branch because the last commit was on a two digit
day (so the digit padding wasn't needed or expected, it checked "Jan 30" ==
"Jan 30", but today "Feb 4" != "Feb 4")
* Bypassing validiation for data script
Prior to this commit, we attempted to run a script against all articles
using validation. In the case of DEV, we have lots of articles that
would no longer validate. This change now updates the column value
without running validation.
Relates to #16075
* Bump for travis
* Add boolean attribute main_image_from_frontmatter to indicate if cover image was set via frontmatter
* use article model spec for main_image_from_frontmatter test cases
* Add data migration script and spec for main_image_from_frontmatter for articles
* Update app/models/article.rb
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
Co-authored-by: Michael Kohl <me@citizen428.net>
Prior to this commit we had an inline logic check on whether or not to
render a navigation link. As we are looking to rollout the feature flag
for Listings, we needed to add another somewhat complex conditional.
This commit moves the inline conditionals to a helper function, which
makes testing the logic far easier. Especially since we need to bombard
the tests with the combination of 3 different boolean checks. (And one
of those boolean checks requires even more but could be stubbed).
There should be no UI differences, as we're presently assuming the
Listings feature is enabled.
Related to forem/rfcs#291
This failed in a main build today, testing shows this may give the
same domain very rarely
10_000.times.map do
Addressable::URI.parse(Faker::Internet.url).domain == Addressable::URI.parse(Faker::Internet.url).domain
end.tally
=> {false=>9998, true=>2}
Use a .dev domain (which is absent from faker's internet domain_suffix
list at
https://github.com/faker-ruby/faker/blob/master/lib/locales/en/internet.yml)
to ensure two unique domains are compared.
remove link to faker internals
* move home link to a customisable navlink
* add trailing slash for path
* update specs
* replace positions, set home link to -1
* add update script for adding home navigation link
* update data update script
* Removes FeatureFlag.enabled?(:creator_onboarding) from codebase
* Removes FeatureFlag.enabled?(:creator_onboarding) from specs
* Further cleanup, removal, and spec fixes
* Fixes the user_request_confirmation_spec.rb
* Reverts change to confirmation email button
* Revert revert after looking at designs again :(
* Removes redundant logo_png field from config + fixes test
* Rewords an expectation in user_uses_the_editor_spec.rb
* Revert removal of logo_png from Config images
* Removes CSS class from user_uses_the_editor_spec.rb
* Removes test from user_uses_the_editor_sepc.rb
* Removes unnecessary else from _logo.html.erb
* Adds back removed system spec
* Removes SVG-related code from _logo.html.erb
* Removes AsyncInfoController#use_creator_onboarding
* Fixes spec failues due to removed code
* Removes svg-related code (that I thought I removed already :/ )
* Re-removes FeatureFlag and logo_svg from _images.html.erb
* Remove newest instances of FeatureFlag(:creator_onboarding)
* remove instances where we use the creator_onboarding field from the base_data
* fix: redirect to the correct path in the reguistrations controller based on whether the user is a creator or not
Co-authored-by: Ridhwana <ridhwana.khan16@gmail.com>
* Unnecessary pages have been disallowed to index by search engines on robots.txt
* Unnecessary pages have been disallowed to index by search engines on robots.txt
* Necessary pages have been added back to the robots.txt.
This provides a test environment database for anyone using a docker
based development environment.
Expose, rather than bind, the db port (you won't be able to connect to
the db externally, only from the container).
Add tmpfs storage (this alleviates an issue seen with carrierwave
attachments when trying to write to the tmp directory in the image).
Upgrade db versions from 11 to 13 (this is a breaking change for
anyone using this who had already provisioned the db, since no attempt
to upgrade has been provided, users may either downgrade to the
11-alpine image or recreate their storage volume). This is
separable (the `db` container was preexisting so is the only upgrade
conflict for users, the `testdb` container is newly created in a newly
added volume, and should not rely on persistence).
It's possible no volume is needed for the test db (only the schema
would normally be persisted, since data is truncated after normal test completion).
