[ITA-SSO_FRONT] Discussion on Initial Development and Configuration of sso_front (#799)

[missvader]

Description:

Hello team,
This discussion focuses on the initiation of the development for the sso_front component in relation to issue #799, titled "[FE] Start with sso_front".

Objective:

• Establish an initial structure for the files and folders of the sso_front project.
• Set up Continuous Integration (CI) to ensure automated building and testing of the code.

Proposed Steps:

1. Create a basic structure of folders and files for the sso_front project.
2. Initiate the CI setup to ensure automated building and testing of the code.
3. Iterate through any challenges and issues encountered during the development process.

[octapf]

Breaking the ice!

I have a question.

• How do we start testing the structure?

I remember Kevin saying it would be nice if each of us tries to do it on its own

[marmorrei]

I agree we all have to understand what the structure is and how it works but, do we have to do repeated work? Or instead agree on what config will do each one of us and then share it with the rest? I am speaking from total ignorance...

[missvader]

I believe that precisely because we are a team, we should organize ourselves a bit.
Perhaps, initially, we should look for some documentation on SSO in the front end and how to implement it.
Then create a basic outline of the structure we need and the steps to follow.
And from there, we can divide the work into tasks

[missvader]

My idea is for us to understand what we need and what we should do. I believe that a visual schema of the structure would be beneficial for all of us.
And I think that repeated work is not a good idea.
Just my opinion

[missvader]

We need to set up a new application, a front end, following the same structure as we have in ita-wiki. During the configuration phase, we have to link it to the existing SSO.

[missvader]

For now, inside src folder, we need all these empty folders and a vite-env.d.ts file

[marmorrei]

Do you think it is best to create all the folders inside src first and after that initialise the react-vite project or the other way around?

[missvader]

I suppose initializing first, as that will already create many of the folders we need. What do you think?

[marmorrei]

Yes, I think so, because anyway it will have to be done, so we use whatever vite create for us.

[missvader]

Assuming everyone is on board with this approach, we could break down the task into subtasks:

1. Create the initial structure of `sso_front`, empty.
   

2. Configure `package.json`, `tsconfig`, `dockerfile`, `eslint`, `prettier`, and `vite.config`. (Here, we need to set up a proxy to connect with 
   

   SSO)

3. Configure tests in the `src` folder.
   

4. Implement coverage and integrate with SonarCloud.
   

This could serve as a task checklist.
And I believe the best way to approach this would be by creating a main branch for the issue, and from there, create sub-branches for each of the tasks.

[marmorrei]

I've just realised that we have to modify the names of the issues to match naming conventions... can we do that on the issue itselt??

[marmorrei]

I guess it has to be with [FE] at the beginning?? or [FE] [SSO]?

[missvader]

You can edit the issue itself. Maybe [FE] [SSO] ?

[missvader]

I have created a main branch where we can submit pull requests for branches related to different tasks/issues.

[marmorrei]

I have modified the [FE][SSO] + labels and project inside each issue

[marmorrei]

Hello again guys!

As Kevin mentioned during the daily, he wants the PR of the final configuration to be able to see that is working.
That means we need to finish the last 2 list items from the checklist that @missvader did (#799) and whatever else is needed. I will assign one to myself to see what I can do.

Also, he doesn't want to see the pr's from the sub-branches to the branch of the issue #799. If I am not mistaken, I think he said yesterday for everyone working on this issue, to commit to the branch of the issue #799 and then, when doing PR to 'main', squash all the commits. Do we continue in this way then?

And one last thing: do we merge directly the PR #818 ??

[missvader]

I think it’s about merging the pull requests of the tasks into the main issue branch ourselves, and when the main issue is ready, then we request a review

[marmorrei]

Ok, then we continue same way, but merging directly the sub-branches.