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

required changes for local setup #1

Merged
merged 25 commits into from
Feb 11, 2025
Merged

Conversation

davidverdu
Copy link

@davidverdu davidverdu commented Jan 28, 2025

As the FE is build process generates static CSS and JS, configuration parameters in the form of environment variables need to be available during build time. As well, there is a configuration check that runs within the application to verify that the expected configuration parameters are available to the application.

There are different approaches to address this issue so that the application has the right configuration for the environment that is going to be deployed into. The chosen approach is to build the application as part of the runtime startup script and pass the configuration parameters as environment variables at runtime.

Changes

  • creatd startup script: entrypoint.sh to execute build and run the application.
  • Refactored Dockerfile to remove build step.
  • Refactored how env variables are loaded to consolidation into a single method from the Vite framework.
  • Removed env module as this is not necessary after refactor.
  • Removed loading of .env.okta properties and loading mechanism as this is not necessary after refactor.
  • Updated vite.config.js to make it closer to the version from main branch.

Notes:

  • The changes to the env variables in this PR will require the parent project to be updated to use ./okta-linking-frontend/.env in Docker Compose

.dockerignore Outdated
#!.development.env
!.development.env
Copy link
Author

Choose a reason for hiding this comment

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

README says that this line should be uncommented to make it work locally

Copy link

Choose a reason for hiding this comment

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

At runtime, not to be committed. README also says DO NOT COMMIT SECRETS HERE. Secrets management did not exist, so this was a first pass. Let's discuss options for secrets management that does not involve committing them to the repo.

env/env.js Outdated
const ENV_FILE = '.production.env';
const ENV_FILE = '.development.env';
Copy link
Author

Choose a reason for hiding this comment

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

README says that this change should be applied to make it work locally. Without this change, docker compose was not working properly

Copy link

Choose a reason for hiding this comment

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

At runtime, not to be committed. I'm getting the impression that the kludge I made for secrets management works but is non-intuitive. Let's discuss how this could be made better.

Copy link
Author

Choose a reason for hiding this comment

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

OK. I think that the code of env/env.js is complicating how env variables are passed. I believe that declaring a .env file is enough to make dotenv load the variables

Copy link

Choose a reason for hiding this comment

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

I agree that seemed peculiar to me also and I was not certain of the developer's intentions. It would be better if we could do this in a more standard way.

@davidverdu davidverdu self-assigned this Jan 28, 2025
@davidverdu davidverdu requested a review from whorka January 28, 2025 18:23
Copy link

@whorka whorka left a comment

Choose a reason for hiding this comment

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

The change to the Dockerfile looks good but the changes to secrets management are not appropriate. Please rescind them and let's talk about a better way to do secrets management.

@davidverdu
Copy link
Author

I left the PR only with the Dockerfile bug fix. Let's discuss the secrets management.

@davidverdu davidverdu requested a review from whorka January 29, 2025 13:36
vite.config.js Outdated

dns.setDefaultResultOrder('verbatim')
dotenv.config()
Copy link
Author

Choose a reason for hiding this comment

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

The env variables are already loaded from memory with process.env. However, I left this clause in case users wanted to run the frontend without Docker, so that a .env file can be used in this folder

Copy link

Choose a reason for hiding this comment

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

Please revert this change to the behavior in the main branch. If the behavior in the main branch does not break any required functionality, we will want to keep the code as close as possible to main so that we can continuously pull in upstream changes easily. Lets limit ourselves to only adding required functionality.

Copy link

@whorka whorka left a comment

Choose a reason for hiding this comment

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

Small change requested but overall this is a big improvement. Thank you!

Copy link

Choose a reason for hiding this comment

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

This change is inconsequential; please remove it.

Copy link
Author

Choose a reason for hiding this comment

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

done

Copy link

Choose a reason for hiding this comment

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

re-committing this to remove .development.env

vite.config.js Outdated

dns.setDefaultResultOrder('verbatim')
dotenv.config()
Copy link

Choose a reason for hiding this comment

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

Please revert this change to the behavior in the main branch. If the behavior in the main branch does not break any required functionality, we will want to keep the code as close as possible to main so that we can continuously pull in upstream changes easily. Lets limit ourselves to only adding required functionality.

Copy link

@whorka whorka left a comment

Choose a reason for hiding this comment

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

Looks even better than before, but I still think we can bring it even closer into line with upstream. Would you be willing to make one more pass on this Aday?

.okta.env Outdated
Copy link

Choose a reason for hiding this comment

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

Why delete this file and load the environment variables from a .env file? Why not just load this file like the main branch does?

README.md Outdated
@@ -6,10 +6,11 @@ Notes:

Amendments:
* Configuration:
1. Copy `.example.env` to `.development.env` and fill in values.
2. Edit `env/env.js` to load `.development.env` instead of production env (FIXME: this should be paramaterized).
1. Copy `.example.env` to `.env` and fill in values.
Copy link

Choose a reason for hiding this comment

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

As above, why is this file now named .env instead of .okta.env?

vite.config.js Outdated
customEnv[key] = env[key]
})

dns.setDefaultResultOrder('verbatim')
Copy link

Choose a reason for hiding this comment

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

Can you see any reason why our Okta PS consultant added this? It appears superfluous since it is setting the default option and should only make a difference if IPv6 is misconfigured. https://nodejs.org/api/dns.html#dnssetdefaultresultorderorder

I'd prefer we remove this and

import dns from 'dns'

if they are not needed, as long as we are cleaning up this file.

Copy link

Choose a reason for hiding this comment

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

Looking into this...

Copy link

Choose a reason for hiding this comment

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

Looking at the Vite docs, this option is to configure the server that runs Vite and serves the React app to the user.
Seems that there are cases that if the configured domain to server the app resolves to multiple IPs (like localhost), Vite might not serve the request if there is a mismatch between Browser and server. This dns fix is used to address it. From the docs: https://vite.dev/config/server-options

I tested without and it works as before. Not sure it was happening to the Okta PS consultant.

We can remove and test the results in an environment to see if is necessary

Copy link

Choose a reason for hiding this comment

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

This is now removed

@abujeda
Copy link

abujeda commented Feb 10, 2025

Sorry for the delay but I didn't get any notifications. I just realized that because I only updated the description and haven't made any comments yet, I wasn't in the list of recipients for notifications.

Looking into the comments and making the necessary updates

Copy link

@whorka whorka left a comment

Choose a reason for hiding this comment

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

I reviewed and recommitted .dockerignore (removing .development.env) and .okta.env (restoring from upstream). Aside from that there are just a couple small documentation fixes. I tested and it works fine. Please commit the doc changes if you agree and this can be merged.

Copy link

Choose a reason for hiding this comment

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

re-committing this to remove .development.env

@whorka
Copy link

whorka commented Feb 11, 2025

If you plan to test you will need to pull hmdc/okta-linking-app:main since I committed an update there to read okta-linking-frontend/.okta.env instead of okta-linking-frontend/.development.env

abujeda and others added 2 commits February 11, 2025 18:02
Co-authored-by: William Horka <[email protected]>
Co-authored-by: William Horka <[email protected]>
@abujeda
Copy link

abujeda commented Feb 11, 2025

Changes looks good!! I have merged the changes.

This is ready to merge to main

@whorka
Copy link

whorka commented Feb 11, 2025

Changes looks good!! I have merged the changes.

This is ready to merge to main

Thank you! Let's merge to linkingapp for now. I intend to rebase all of linkingapp on top of okta-samples/okta-react-sample:main

@whorka whorka merged commit 4e08e4b into linkingapp Feb 11, 2025
1 check passed
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.

3 participants