Skip to content
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

3465 - Make sure pender works with PostgreSQL 13 #373

Merged
merged 1 commit into from
Aug 7, 2023

Conversation

vasconsaurus
Copy link
Contributor

Description

Upgraded Postgres to 13. Used the same image Devin used for Alegre.

References: 3465, 3464, 3468

How has this been tested?

Made some requests to pender manually, they all worked.

I had upgraded to postgres12-bullseye because of a issue we had when
building on Travis:
We had an issue with building on Travis that seems related to a change
the maintainers of the postgres docker images have made to the underlying
OS image layer: Previous: Debian 11 (bullseye) New: Debian 12 (bookworm).
The workaround seems to be using postgres-bullseye.More on this here
https://stackoverflow.com/questions/76555305/postgres-container-failed-to-start-with-initdb-error-popen-failure-cannot-allo/76591040#76591040

Now updating to 13 I checked which image Devin used in Alegre and am
using the same one here.
Copy link
Contributor

@caiosba caiosba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to go once tests pass.

@vasconsaurus
Copy link
Contributor Author

Good to go once tests pass.

we only have those two facebook tests failing

@caiosba
Copy link
Contributor

caiosba commented Aug 7, 2023

Good to go once tests pass.

we only have those two facebook tests failing

Good to go then! :)

@vasconsaurus vasconsaurus merged commit 5ffd289 into develop Aug 7, 2023
3 of 4 checks passed
@vasconsaurus vasconsaurus deleted the 3465-ensure-pender-works-with-postgres13 branch August 7, 2023 14:28
vasconsaurus added a commit that referenced this pull request Aug 8, 2023
- We don't need that many integration tests, so we are moving some of them
back to test/models/parser/twitter_item_test.rb, and updating them to not
make live requests, instead they will be stubbed.

- I added tests to check the basic request functionality that we now have.
And removed "assigns values to hash from the API response" since that is already
being tested in "it makes a get request to the tweet lookup endpoint successfully"

- "should decode html entities" was removed because that happens
inside Media and is not done by the individual parser, which means
the test actually fails (as it should)

- fake_tweet and fake_twitter_user were removed, since they used
methods from the old Twitter gem. Now we are stubbing a response from
our new method: tweet_lookup

- added .squish to parsed_data['raw']['api']['data'][0]['text'] to clean up
line breaks from title and description. Our test was failling because it was
not being removed. also since title and description are the same, I just
set the description to be the same as the title instead of parsing twice.

- separated the stub from the response, so we can also have a failed response.
changed the response fixture to be a success one, and added an error one

- changed the id and user to make it clear that those are fake and being stubbed.

- Removed the test for truncated text, that behavior is no longer present
in the v2 api, only retweets might be truncated (we don't fetch those),
and the way to deal with it is different. It does not take truncated as a
query param.

- @url.gsub!(/\s/, '') -> remove whitespaces from the url

- raise ApiError.new("#{e.class}: #{e.message}") -> I can get the response
code and body, but I get an error when I try the same for the error

- upgrade postgres image to 13 (#373)

I had upgraded to postgres12-bullseye because of a issue we had when
building on Travis:
We had an issue with building on Travis that seems related to a change
the maintainers of the postgres docker images have made to the underlying
OS image layer: Previous: Debian 11 (bullseye) New: Debian 12 (bookworm).
The workaround seems to be using postgres-bullseye.More on this here
https://stackoverflow.com/questions/76555305/postgres-container-failed-to-start-with-initdb-error-popen-failure-cannot-allo/76591040#76591040

Now updating to 13 I checked which image Devin used in Alegre and am
using the same one here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants