-
Notifications
You must be signed in to change notification settings - Fork 9
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
Implement Deployment Workflow to Dev, Nix Flake Configuration, Fixes: eslint,tsc file hash matching and Code Refactoring #549
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tag is created (from a specific pattern) The existing GitHub workflow has been modified to introduce automated triggering for deployments to the `dev` branch on the development server upon the creation of a new tag that matches the pattern `refs/tags/dev-`. The workflow can now distinguish between automated activation triggered by specific tag creation and manual activation by the user. By adding a new workflow configuration file, `.github/workflows/deploy-dev-from-tag.yml`, the automation process for deployments has been enhanced to react promptly to tag creation events following the specified pattern. Changes: - Created a new GitHub workflow configuration file, `deploy-dev-from-tag.yml`, to facilitate automated deployment activation based on tag creation matching the predefined pattern `refs/tags/dev-`. - Configured the workflow to differentiate between automated triggering upon tag creation and manual activation. - Updated the workflow to respond effectively to tag creation events following the specified pattern, ensuring seamless deployment processes and providing the flexibility of manual activation as required.
…flow-to-trigger-on-new-tags-matching-pattern [#498] Modify Github Workflow to trigger on new tags matching pattern
…flow feat/new-drep-registration-flow
…pe-errors-in-frontend-package [#514] chore: fix eslint and typescript errors
…orted-as-not-matching fix/510-file-is-wrongly-reported-as-not-matching
Implementing Nix Flakes requires the creation of a default entrypoint for scripts to ensure that that application module can be effectively combined within the project structure. This default.nix file includes a shell definition with necessary build inputs such as awscli, curl, docker, git, gnumake, openssh, and rsync. By adding this default entrypoint, developers can utilize Nix Flakes to streamline the combination of application modules within the project.
The commit introduces a `flake.lock` and `flake.nix` file, defining the project's dependencies and configuration. The `flake.nix` file sets up a Nix Flake for the GovTool and utilities monorepo, specifying inputs from nixpkgs and generating packages for supported systems such as x86_64-linux, aarch64-linux, x86_64-darwin, and aarch64-darwin. Additionally, the `scripts` attribute is included to allow for a scripts environment from `scripts/govtool`, ensuring a versatile Nix-shell setup for all supported systems.
The user story requires utilizing Nix Flakes to combine application modules within a project to enhance manageability and organization. In this commit, the .envrc example was relocated from `scripts/govtool/.env.example` to the root directory as `.env.example`. By moving this file, we align with the objective of making the application modules accessible from the root of the project. The modification ensures that the necessary environment configuration template is centrally located, facilitating the use of Nix Flakes for streamlined module combination. Changes: - The `.envrc` example file has been moved from `scripts/govtool/.env.example` to the project's root directory as `.env.example`. - The file contents were adjusted to remove references to the previous directory structure and updated to indicate the use of Nix Flakes configuration. - The relocation enhances accessibility and clarity, aligning with the goal of effectively combining application modules using Nix Flakes for improved project structure and management.
The user story necessitates utilizing Nix Flakes to combine application modules within the project for better organization and manageability. This commit integrates the backend environment into the Nix Flakes as one of the outputs, aligning with the objective of enhancing accessibility and usability of application modules from the project's root. By adding the backend as an output, developers can effectively combine and utilize the backend environment using Nix Flakes for improved project structure and management. Changes: - Added the backend environment as an output in the `flake.nix` file. - Modified `govtool/backend/default.nix` to include the recommended Haskell compiler version and additional tools needed for the backend. - Updated the entrypoint to provide necessary build inputs and display a welcome message for the backend development shell. - Removed unnecessary files `shell.nix` and `sources.nix` related to the backend environment setup.
Integrating the infrastructure environment into the Nix Flakes configuration is crucial for combining application modules effectively within the project structure. By updating the `flake.nix` file, the infrastructure environment is now part of the Nix Flakes configuration, enabling streamlined access and utilization of infrastructure-related tools. The changes include incorporating the infrastructure package in the `flake.nix` file, moving `default.nix` to infra/terraform directory, and removing unnecessary files related to the shell environment setup. This enhancement aligns with the user story's goal of utilizing Nix Flakes to combine application modules for improved project organization and accessibility. Changes: - Added the infrastructure package to the `flake.nix` configuration for Nix Flakes. - Moved `default.nix` to the `infra/terraform` directory to establish the infrastructure environment setup within the project. - Removed unnecessary files related to the shell environment setup in the `infra/terraform` directory to streamline the project structure.
The purpose of this commit is to create .envrc files within specific modules that reference the root .envrc file and utilize the corresponding flake for configuration. By establishing these .envrc files in the `backend`, `infra`, and `scripts` modules, the project enhances the organization and management of application modules using Nix Flakes. This setup ensures that each module aligns with the root configuration, streamlining the usage of Nix Flakes for combining application modules effectively within the project structure. Changes: - Renamed .env.example to .envrc.example, ensuring consistency in naming conventions. - Added a new .envrc file in the `govtool/backend` directory, referencing the root environment and using the corresponding flake for the backend module. - Created a .envrc file in the `infra/terraform` directory, linking to the root environment and utilizing the appropriate flake for the infrastructure module. - Introduced a .envrc file in the `scripts/govtool` directory, pointing to the root environment and leveraging the matching flake for the scripts module setup.
…f the project The relocation of the DOMAIN definition from the subdirectory specific .envrc files to the master .envrc file in the root directory streamlines the access to and management of environment variables within the project. As per the user story requirements to enhance organization and accessibility of application modules using Nix Flakes, this adjustment ensures that the domain configuration is centralized, simplifying the integration of the application modules. By consolidating this setting in the main .envrc file, developers can effectively coordinate and utilize the domain configuration across different project components, aligning with the goal of leveraging Nix Flakes for improved project structure and ease of use. Changes: - Moved the DOMAIN definition logic from individual .envrc files to the main .envrc file in the project's root directory. - Updated the .envrc.example file to reflect the changes in domain configuration logic for different environments. - Streamlined domain configuration setups for various environments (dev, test, staging, beta) within the central .envrc file, enhancing clarity and accessibility for developers working on the project.
Integrating a frontend module into the Nix Flakes configuration is essential for combining application modules within the project effectively. The frontend module's addition is in alignment with the user story's goal of utilizing Nix Flakes to enhance project manageability and organization. By including the frontend module, developers can streamline the usage and integration of frontend-related tools and configurations, fostering a cohesive structure for the application. This commit expands the project's capabilities by incorporating a frontend module into the Nix Flakes setup. Changes: - Integrated the `node_nixpkgs` input to the `flake.nix` file, allowing for frontend-specific dependencies in the Nix Flakes configuration. - Created a `.envrc` file within the `govtool/frontend` directory, defining environment variables for the frontend module and setting up the necessary configurations. - Updated the Dockerfile in the `govtool/frontend` directory to include variables related to the Vite base URL and other frontend settings. - Adjusted the `default.nix` file in the `govtool/frontend` directory to enhance the frontend project configuration and provide a tailored development shell setup. The update includes a welcome message and necessary cleanup processes for improved project development experiences.
Provide comprehensive documentation on utilizing Nix with the project to enhance development processes and streamline environment setup. The .envrc files are updated to ensure compatibility with Nix configurations, facilitating package installation and project building. This documentation emphasizes the use of Nix and Direnv for effective project setup and module combination within the GovTool project structure. Changes: - Updated `README.md` in `govtool/backend` to include instructions for utilizing Nix and Direnv, aligning the setup with Nix Flakes configuration. - Revised `README.md` in `govtool/frontend` to streamline instructions for using Nix and Direnv, ensuring proper environment setup and dependencies for the frontend module development.
Implementing Nix Flakes is essential to combine application modules within the project, ensuring easy access and utilization from the root directory. By adding the Nix Flakes configuration in this commit, developers can streamline the setup process for various modules, enhancing project manageability and organization. This aligns with the user story's goal of leveraging Nix Flakes for improved accessibility to and usage of application modules. Changes: - Included Nix Flakes configuration to manage unified developer setups effectively. - Enhanced the project structure by enabling easy access and utilization of application modules from the root directory. - Streamlined the setup process for different modules, ensuring consistency and ease of use within the project environment.
…flakes-to-combine-application-modules-for-root-project-access [#526] Implementing Nix Flakes to combine application modules for root project access
Co-authored-by: Bartłomiej Sworzeń <b.sworzen@gmail.com>
[#522] chore: refactor pending transaction
…a-dashboard [#539] fix: endless spinner on a dashbord
…tests-are-broken [#500] chore: fix frontend package tests
The changes made include updating the CONTRIBUTING.md document to include moving the ticket to the 'in review' status when the PR is ready for review, changing the state of the PR from draft to actual PR, addressing all change requests before merging the branch into `develop`, and automating the deployment process to the test and staging environments. These modifications aim to streamline the development workflow by ensuring that tickets, PRs, and branches are managed efficiently during the development and review phases.
…ng-guidelines-to-reflect-latest-assumptions [#506] Update contributing guidelines to reflect latest assumptions
pmbinapps
requested review from
placek,
adgud,
kickloop,
MSzalowski,
jankun4,
Sworzen1 and
JanJaroszczak
as code owners
March 25, 2024 12:43
MSzalowski
approved these changes
Mar 25, 2024
pmbinapps
changed the title
Implement Deployment Workflow to Dev, Nix Flake Configuration, Critical Bug Fixes, and Code Refactoring
Implement Deployment Workflow to Dev, Nix Flake Configuration, Fixes: eslint,tsc file hash matching and Code Refactoring
Mar 25, 2024
This was referenced Apr 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add:
[#498] Implement a workflow that triggers deployment to dev when a ...
[#526] Add a default entrypoint for scripts
[#526] Create a Nix Flake and Default Entrypoint
[#526] Move the .envrc example to the root directory
[#526] Incorporate backend environment into Nix Flakes as an output
[#526] Apply infrastructure environment to the Nix Flakes configuration
[#526] Add modules .envrc files
[#526] Add a frontend module to Nix Flakes
[#526] Add documentation on Nix usage
[#526] Add Nix Flakes configuration to handle unified developer setups
Fix:
[#514] chore: fix eslint errors
[#514] chore: fix tsc errors
[#513] chore: remove postinstall-postinstall package
[#513] fix: fix code check workflow
[#510] fix file doesn't match to existed hash
[#539] fix: endless spinner on a dashboard
Change:
refactor step1 and step2 for drep registration
Store data for drep
[#526] Move DOMAIN definition to the master .envrc file in the root o…
[#522] refactor useTransactions hook
[#522] check if DBSync updated after transaction
[#522] delete unnecessary code
[#506] Adjustment the contributing guidelines to reflect recent changes