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

Implement Deployment Workflow to Dev, Nix Flake Configuration, Fixes: eslint,tsc file hash matching and Code Refactoring #549

Merged
merged 41 commits into from
Mar 25, 2024

Conversation

pmbinapps
Copy link

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

Sworzen1 and others added 30 commits March 20, 2024 14:14
…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
…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
j-dyczka and others added 11 commits March 22, 2024 14:32
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 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
@pmbinapps pmbinapps merged commit cf1c0aa into test Mar 25, 2024
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.

6 participants