-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix PostgreSQL GitHub Action and Tests For Rails 7 Upgrade #3435
Conversation
Addresses the following error that was encountered when attempting to execute the GitHub Actions that correspond with the edited workflows files: https://github.com/DMPRoadmap/roadmap/actions/runs/9513143079/job/26222602325 3s ``` Run bundle exec rails db:create RAILS_ENV=test To use retry middleware with Faraday v2.0+, install `faraday-retry` gem To use multipart middleware with Faraday v2.0+, install `faraday-multipart` gem; note: this is used by the ManageGHES client for uploading licenses Copying Bootstrap glyphicons to the public directory ... Copying TinyMCE skins to the public directory ... /home/runner/work/roadmap/roadmap/config/initializers/recaptcha.rb:8:in `block in <main>': undefined method `[]' for nil:NilClass (NoMethodError) from /home/runner/work/roadmap/roadmap/vendor/bundle/ruby/3.0.0/gems/recaptcha-5.17.0/lib/recaptcha.rb:37:in `configure' from /home/runner/work/roadmap/roadmap/config/initializers/recaptcha.rb:7:in `<main>' ```
Prior to this commit, the Rails credentials were not being updated during this setup process.
Here are links to the errors being raised prior to this commit: https://github.com/DMPRoadmap/roadmap/actions/runs/9822436610/job/27119190298?pr=3435 https://github.com/DMPRoadmap/roadmap/actions/runs/9822436613/job/27119190303?pr=3435 https://github.com/DMPRoadmap/roadmap/actions/runs/9844975903/job/27179509035?pr=3435
b06baf9
to
727c2e8
Compare
This commit undoes some Rubocop fixes made from a prior commit ( bda5b6e ). However, it also resolves the following error that was being raised: https://github.com/DMPRoadmap/roadmap/actions/runs/9845084297/job/27179836711
Generated by 🚫 Danger |
The failing tests still need to be addressed for the PostgreSQL GitHub action, but the workflow is now executing. The MySQL GitHub action is still failing to execute. Many errors like the following are being thrown:
These errors are related to the migrations added to #3426. When the migrations were run, many tables not targeted by the migrations were also updated. Here is an example: # before running migrations
create_table "orgs", id: :integer, force: :cascade do |t|
# after running migrations
create_table "orgs", id: :serial, force: :cascade do |t| It seems that I'm not sure how to proceed here. Should we simply retire the MySQL GitHub Actions? Or perhaps re-running the migrations with a MySQL db would re-cast the primary keys to type Wondering what your thoughts might be here @benjaminfaure and @briri. Thank you. |
Omitting the arguments results in lambda implicitly using self, which appears to be the desired behaviour here. It also resolves the Rubocop offences.
There are now two failing tests within the PostgreSQL workflow. Although the tests were passing prior to this Rails 7 upgrade, there were known issues prior to it:
Failures:
1) Template#customize! sets visibility to Organisationally visible
Failure/Error: expect(subject.visibility).to eql(Template.visibilities['organisationally_visible'])
expected: 0
got: "organisationally_visible"
(compared using eql?)
# ./spec/models/template_spec.rb:1086:in `block (3 levels) in <main>'
2) Template#upgrade_customization! sets the visibility to Organisationally visible
Failure/Error: expect(subject.visibility).to eql(Template.visibilities['organisationally_visible'])
expected: 0
got: "organisationally_visible"
(compared using eql?)
# ./spec/models/template_spec.rb:1155:in `block (3 levels) in <main>' |
`template.visibilty` now returns a string rather than an integer. The Rails 7 upgrade actually fixes a couple of bugs within `app/views/org_admin/templates/_form.html.erb` and `app/views/org_admin/templates/_show.html.erb`. Prior to this upgrade, template.visibility would return an integer. Now that it is returning a string, the `f.object.visibility == 'organisationally_visible'` and `template.visibility == 'organisationally_visible'` checks within the aforementioned files are behaving as desired.
Prior to this commit, the default checked/unchecked values were used (i.e. "1" would be returned when checked, and "0" would be returned when unchecked). However, the box is meant to be checked when selecting 'organisationally_visible' ('for internal %{org_name} use only'), which makes the default checked/unchecked values opposite to the mapping of our enums (i.e. `{"organisationally_visible"=>0, "publicly_visible"=>1}`).
2f5b0be
to
4bd0e9a
Compare
The aforementioned issues have been addressed, but now the following
|
Rails 7 appears to apply stricter parsing rules. If the Content-Type is application/x-www-form-urlencoded, the body will not be parsed as JSON. The following code changes throughout the codebase seem to resolve this: # Old Code
post api_v1_authenticate_path, params: @payload.to_json
# New Code (use `as:` for encoding the request's content type)
post api_v1_authenticate_path, params: @payload, as: :json |
Rails 7 appears to apply stricter parsing rules. If the Content-Type is not JSON, then the body will not be parsed as JSON.
a9213e1
to
d06f436
Compare
Prior to this code change, any value assigned to the `'data-method':` attribute of the `link_to` method was not being read (and instead defaulting to `GET`). This was resulting in the breaking of several `spec/features/` tests (https://github.com/DMPRoadmap/roadmap/actions/runs/9946998559/job/27478725801). The `@rails/ujs` library is meant to handle this `'data-method':` attribute.
Hi @benjaminfaure, thanks for the approval on this PR. I added a couple more commits, so maybe it'd be best to get one more review/approval before I merge it into your Rails 7 upgrade branch? Thank you. :) |
Fixes #3419
Changes proposed in this PR:
This PR seeks to fix the PostgreSQL GitHub Actions for PR Updated app to rails 7 #3426 (NOTE: Fix PostgreSQL GitHub Action and Tests For Rails 7 Upgrade #3435 (comment) explains why the MySQL GitHub Action is still not working)
config/credentials.yml.mysql2
andconfig/credentials.yml.postgresql
had to be updated for the Rails 7 upgrade.DISABLE_SPRING=1
has been added to the test db setup commands. Without disabling Spring, the test db was failing to build with the Rails 7 upgrade.The
Style/SymbolProc
-related Rubocop fixes applied in commit bda5b6e have been undone. Although executingrubocop -A
results in these changes, those changes were causing errors within the code. (To address these Rubocop offences, commit 283e585 has been added instead.)This PR also fixes failing tests executed by the PostgreSQL GitHub Action. These changes include the following:
Template.visibility
output"@rails/ujs"
. Many of thespec/features/
were failing without the now updated ES6 module syntax.This PR also resolves the GitHub issue Template.visibililty Checks Not Always Working as Expected #3419.
Template.visibilty
; thus, the issue is resolved here.