When we test our code coverage compilation, it breaks the code coverage
report for the current rspec process. By running that code separately,
we gain a correct coverage report for the rest of the code again.
So unfortunately, we can't report on the code coverage of this
particular task and have to ignore it. But at least CI depends on the
correct function of this task and would fail if it didn't work.
Apparently, Rake's way of reloading the task code confuses the code
coverage report. Code tested by rake task specs was not recognised as
covered even though it was.
- Cop: Rails/RelativeDateConstant
- raises offense if Constant is relative data (ie: since, ago)
- Reason: relative data will be evaluated only once
- BUT here, Date should not be evaluated in a class method, and have a different
- value for each call. But the data should be the same for an instance
- Therefore: move the ago in init method
- Cf. https://docs.rubocop.org/rubocop-rails/cops_rails.html#railsrelativedateconstant
- Since there is no constant to be called form a class, but a date from an instance, the
spec has been modified accordingly. The RemoveTransientData.new.call had to be splitted.
The new product image import spec was loading rake tasks multiple times.
That make the spec for enterprise deletion fail when executed afterwards
because the deletion task was executed twice and failed the second time.
Active Storage needs a checksum for each file and AWS S3 provides this
checksum as "ETag". They are both MD5 but AWS stores it as hexdigest and
Active Storage as base64digest. We need to convert it from on to the
other to get a valid checksum for Active Storage.
Where the migration task has already run (only staging servers), delete all
Active Storage data first and then run the task again:
bundle exec rake db:migrate:down VERSION=20220316055458
bundle exec rake db:migrate
bundle exec rake from_paperclip_to_active_storage:copy_content_config
bundle exec rake from_paperclip_to_active_storage:migrate
Common migrations look for all models with *_file_name attributes but I
found that unreliable in our code base. It finds too many model classes
and doesn't allow us to be more selective in the migration. So I used
our own migration declaration to migrate exactly those attachments
specified.
We removed some Spree magic a while back and that broke our sample data
script. This is now corrected.
I also added a spec so that we will notice broken seed data earlier.
It does so by updating a user's enterprise_limit attribute to the
maximum integer the database supports.
This is used at least in Katuma to remove the limitation of the number
of enterprises a user can create. This is the agreement the community
reached for the pricing plans.
Eventually, this logic could be triggered with a button from the UI but
for now this is for internal usage only.
Note this task is still rather naive and only covers the simple case
where an enterprise was created but never used and thus, does not have
any associated entities like orders.
This is enough for the case I have at hand where a hub's manager created
an enterprise while he wanted to create a user account #ux. He ended up
with an enterprise named after him and now he asked us to clean that up.
