NoMongo: GitHub action to test basic DB access and updates

[palisadoes]

Is your feature request related to a problem? Please describe.

Our GitHub actions test basic functionality, but don't test key functionalities on live data.

Describe the solution you'd like

Create GitHub actions that test the importation of sample data

1. Validate the existence of data in all tables
2. Update various tables through representative API calls and validate the results

Depends on:

• Setup Script #2952

Describe alternatives you've considered

• N/A

Approach to be followed (optional)

• See above

Additional context

Depends on:

• Setup Script #2952

Potential internship candidates

Please read this if you are planning to apply for a Palisadoes Foundation internship

• Student Internship Programs talawa#359

[JaiPannu-IITI]

@palisadoes please assign

[PurnenduMIshra129th]

@palisadoes please assign.

[JaiPannu-IITI]

Thankyou @dhanagopu

[palisadoes]

@JaiPannu-IITI

When the containers start the src/plugins/seedInitialData.ts file automatically inserts a API_ADMINISTRATOR_USER_EMAIL_ADDRESS user in the DB if none already exists. That is probably the source of the duplicate entry. The sample DB needs to be updated, not the script.

[JaiPannu-IITI]

@palisadoes No sir

Every user should have unique user_id, if we try to use sample data script two times, it was conflicting earlier due to this, I have fixed that thing, now it will not throw error on this. rather if that particular sample data is already present, it will continue adding other data

sample data script is never designed to add API_ADMINISTRATOR_USER in the first place, it was other data that was conflicting which has been fixed,

[JaiPannu-IITI]

Sample data script will not run if API_ADMINISTRATOR_USER is not present, that's why I used seedInitialData helper function here to deal with cases when db is reset intentionally and then user tries to add sample data, then administrator will be recreated, sample data has nothing to do with administrator

I strongly recommend you to try executing sample data and reset scripts in all cases, you'll find out whatever user does like format db, change administrator or change sample data anything, they will not throw error and fulfill their purpose

[JaiPannu-IITI]

#3243

Sir this issue is not related to this, this issue is long existing but came to picture right now since bucket problem solved.

https://palisadoes-foundation.slack.com/archives/CSWH4PN0M/p1738240831597849

For clarity, I added support of pnpm and node to all shells + which already had it.

[palisadoes]

I ran it and it works.

[palisadoes]

What is causing the error

#3243

Sir this issue is not related to this, this issue is long existing but came to picture right now since bucket problem solved.

https://palisadoes-foundation.slack.com/archives/CSWH4PN0M/p1738240831597849

For clarity, I added support of pnpm and node to all shells + which already had it.

PTAL. This is what I was referring to. I had to revert your PR.

#3223 (comment)

[JaiPannu-IITI]

Sir that message is logged by me .. for clarity

[JaiPannu-IITI]

It is not an error

[JaiPannu-IITI]

It is a check to avoid errors in future if someone by mistake resets database then access will be lost, it is a fail safe thing

[palisadoes]

You are misinterpreting two issues.

1. Yes you fixed pnpm with loading the data, but merging the PR started to cause others to fail.
2. The pnpm issue with the production .env file seems to have been introduced somewhere else.

[JaiPannu-IITI]

Sir I got your point

[JaiPannu-IITI]

That error is just due to 2 files integration testing on same database.

[JaiPannu-IITI]

Just give me few minutes I'll fix this

[JaiPannu-IITI]

Actually the problem is that file is creating administrator at same time in test when I am testing creating administrator after a db reset

[palisadoes]

Why did you have to add the path for fnm in the docker file? If fnm installed, couldn't you just run fnm to install the version of node in the ENV variable and then pnpm?

I'm wondering whether your solution could fail in other operating systems (unlikely)

The solution you chose seems too dependent on the location of hidden files. There must be a more conventional way where a symlink is created to the pnpm location by the fnm team verus us. For example sym linking from /usr/bin/pnpm

If fnm changes it's methodology then the installation could break.

[JaiPannu-IITI]

Agreed
Sir I will change this to more dynamic way.