Forem: Eakam

Starchart - Milestone 1.0a

Eakam — Wed, 19 Apr 2023 02:59:17 +0000

Last week, I worked on a bunch of things for our 1.0a (alpha) release:

Adding end-to-end tests for DNS Records
We were missing a large amount of tests for the DNS Records page. This included checking for different types and values of DNS Records when creation so that only valid values for different types can be created. It also included checking that all values were saved properly, checking edit functionality and delete functionality (PR)
Preparing for Remix v2
This was to deal with multiple depreciation warnings as some of the remix specific stuff such as routes, meta tags, ErrorBoundry and CatchBoundry, and the formMethod will change in v2. Therefore, we decided to update to the new methods (PR)
Improving DNS Records table responsiveness
The DNS Records table does not look good on small screens. This was to create a better layout for mobile screens. Further PRs would be created to tackle the view for tablet screens and other screen sizes. I basically ended up using Chakra UI's Show and Hide components to use a different layout on mobile (PR)
Small fixes for some test flakiness (PR), and adding a missing * in emails (PR)

Starchart: Milestone 0.9

Eakam — Mon, 10 Apr 2023 04:37:24 +0000

Last week, I worked on a bunch of bug fixes and features for starchart:

Splitting certificate public key from its chain. The certificate creation process returns the public key for the certificate, and a chain which contains the intermediate certificates. We were storing both of these in the same field, and displaying the data as is. Thus, users would be copying the public key + the chain instead of just the public key (PR)
Adding admin login setup for e2e tests. We have a util function that allows anyone writing tests to easily log in as a user. This needed to be extended to users with the admin role (PR)
Improved landing page responsiveness. We had a couple of cards on the landing page that would shrink horizontally instead of moving to be vertically stacked on smaller screens (PR)
Making links more obvious. We had a bunch of links that looked the exact same as rest of the text. This changed all links to have color red and an underline by default. Since we use Chakra UI, this was specified in the theme file, and thus could be overridden as you would for the base Chakra UI element (PR) :

const theme = extendTheme(
  {
    colors,
    breakpoints,
    components: {
      Link: defineStyleConfig({
        baseStyle: {
          color: 'brand.500',
          textDecor: 'underline',
        },
      }),
    },
  },
  withDefaultColorScheme({ colorScheme: 'brand' })
);

Removed happy-dom. I looked at a dependabot PR to update this package and noticed that we were not using it at all (PR)

Starchart: Milestone 0.8

Eakam — Mon, 03 Apr 2023 11:03:34 +0000

The last week I worked on some additional features for starchart, which are summarized below:

Fixing DNS Record expiry date - PR. The expiry date was always set to July, and thus you could end up with a record created in December which expires in July.
Adding checks for deactivated users - PR. This was needed as we don't want to allow deactivated users (users who are being deleted) to perform any actions. Most of the work here involved looking at the routes and actions, and adding checks where needed but it ended up being a small change.
Attempting to add coverage report for playwright e2e tests - Issue. This issue was created after adding coverage report for unit tests which use Vitest. Playwright does not have a coverage option but we found a possible npm module that could be used for this - playwright-test-coverage. However, after some research, I found that the module requires babel-plugin-istanbul. Since we use remix, we decided that it was not worth the effort to try to add babel plugins to remix as it would risk causing new problems. Apart from this, I spent some time reviewing PRs. You can find the changelog here.

Starchart: Milestone 0.7

Eakam — Mon, 27 Mar 2023 02:37:23 +0000

This past week, I worked on a bunch of small issues for starchart to improve our UI experience, fix some bugs, and update test configuration:

We needed some new scripts to setup a test database to use when running automated tests. This basically involved copying the existing setup script and changing the database url (PR)
Some updates were needed for our vitest configuration. These were mostly small changes, and also another script to add a coverage report for unit tests. This also raised some discussion on adding coverage for out end to end tests. (PR)
A UI change to hide the DNS Records table if none exist for the logged in user. Instead, a create button is displayed in the center. (PR)
Another UI for the DNS Records table to disable the renew record button if the DNS record expiry date 6 months from now or beyond. (PR)
A change to improve the accessibility of some links on the landing page. This was needed as the light blue color didn't provide enough contrast. (PR)

Another issue that I have been working on but was not able to finish the last week is to handle the fact that users can be deactivated. This involves checking for a user being deactivated in multiple places throughout the code as a user could be deactivated while a some jobs are running to update DNS Records, etc.

Starchart: Playwright tests separation

Eakam — Mon, 20 Mar 2023 03:08:37 +0000

The past week, I continued working on different issues in starchart. This involved adding a deactivated flag to users, which was a fairly simple change. This is required as we want to allow admin users to delete users. However, before a user can be deleted, we need to queue up deletion of any DNS records or certificates associated with that user.
This process can take some time, and we needed a way to prevent the user from creating any new DNS records or certificates while they are being deleted. Thus, we decided to add a deactivated flag to users and if this flag is true, they will not be able to perform any actions.

Another issue I worked on was to improve our documentation about Playwright, and more specifically, our configuration and how to use the automated report we generate after a CI run to debug any failing tests (wiki page).
While working on this documentation, I also worked with Ririio with his work on improving our e2e test coverage for various pages. We ran into an issue while testing the header as the links in the header move into a hamburger menu on mobile viewports:

Desktop View:

Mobile View:

Thus, as our playwright config ran the same test file for several browsers, including mobile view ports we would either have failing tests for desktop or failing tests for mobile.

An option was to skip tests if we were on a mobile viewport. However, due to an issue with mobile safari configuration, where it fails on GitHub Actions but passes on Windows (where I was able to test), we had to override the configuration's isMobile property to false as a workaround. So, this would not work. Even then, we would need to add a test.skip to every test we wanted to skip for mobile, and then add another test to only run on mobile.

After some discussion, we decided to use the testIgnore property in the configuration:

projects: [
  ...
  // Desktop projects
  {
    ...
    testIgnore: /.*\.mobile\.spec\.ts/,
  },
  ...
  // Mobile projects
  {
    ...
    testIgnore: /.*\.desktop\.spec\.ts/,
  }

We added mobile specific tests in files ending with .mobile.spec.ts (eg: header.mobile.spec.ts), and desktop specific tests in files ending with .desktop.spec.ts (eg: header.desktop.spec.ts). Any common tests would still go in the usual file (eg: header.spec.ts).
This works as playwright has a testMatch property which by default matches all files using the regex .*(test|spec)\.(js|ts|mjs).

Starchart: Shared sessions in Playwright

Eakam — Mon, 13 Mar 2023 10:14:12 +0000

Last week, I worked on setting up shared authentication for end-to-end Playwright tests in starchart. This was necessary to avoid having to login before every test. The Playwright docs suggest a few different ways of doing this, such as a shared account for all tests, or setting up multiple roles.

I went with a similar setup to the setup you would have for multiple roles with a shared account across all tests that require login. Currently, all the pages do not differentiate between roles, i.e., they do not show different things based on the role. However, a design for an admin dashboard was being worked on, and will be implemented in the upcoming weeks. So, I decided to use a setup that would be easy to expand for different roles such as an admin user.

I started by adding a setup file under my e2e tests folder which would go through the login process, and save the authenticated state in a file:

import { test as setup } from '@playwright/test';
const userFile = 'test/e2e/.auth/user.json';

setup('authenticate as user', async ({ page }) => {
  ...
  // Login steps

  await page.context().storageState({ path: userFile });
});

Then I modified playwright config and added a new project that will be a dependency of all other projects. A project has a name and defines configuration for running the tests on a specific device in this case:

projects: [
  {
    name: 'setup',
    testMatch: /.*\.setup\.ts/,
  },
  {
    name: ...,
    use: {
      ...devices['Desktop Chrome'],
    },
    dependencies: ['setup'],
  },
  ... other projects

By setting setup as a dependency, it will be run before the tests in the project are run. testMatch defines a regex for the setup file(s), and it matches paths relative to the test directory defined in the config.

Since the setup process is run before the tests are run, we actually don't need to commit our file with the saved session to git. Thus, I added it to the .gitignore file.

I also added tests for the New DNS Record form. This form is used by a user to create a new DNS Record. Since this required a user to be logged in, we can use the saved session state generated in the setup project:

test.describe('authenticated as user', () => {
  loggedInAsUser();

Here, loggedInAsUser() is a util function that was added based on PR reviews:

export function loggedInAsUser() {
  return test.use({ storageState: 'test/e2e/.auth/user.json' });
}

test.use can be specified in a describe block or in a test file. It is not necessary to use this in a beforeEach or beforeAll, and doing so would result in an error.

I ran the tests locally, and they all passed. However, I encountered a strange error in CI (which uses GitHub Actions) for the Mobile Safari project:

Test timeout of 30000ms exceeded.

page.goto: Navigation failed because page was closed!

Playwright generates a report containing a video and a trace on the first retry, depending on the configuration. I looked at the video and saw that most of it was a blank black screen. After trying a bunch of things such as upgrading playwright, and commenting out all other projects, I found this open issue on the playwright project. There was a super helpful comment left on the issue with a temporary workaround. Basically, setting isMobile to false for the iPhone configuration used by the Mobile Safari project results in the CI passing on GitHub actions.

Starchart: Week 7

Eakam — Sat, 04 Mar 2023 05:25:10 +0000

For week 7, I continued with my work on the DNS Record creation page. This basically involved resolving all the review comments, and trying to get tests working. However, I ran into another sign in problem in the Playwright test environment:

I did not want to resolve this specific issue in the same PR as the one creating the page so I decided to create a separate issue for it.

While working on the DNS Record creation page, I rebased my branch with the main branch as it had gotten out of date. After this, I found that I could no longer run the app, and got this error:

'SECRETS_OVERRIDE' is not recognized as an internal or external
command, operable program or batch file.

I saw that the dev script had been modified to override an ENV variable:

"dev": "SECRETS_OVERRIDE=1 run-p dev:*"

However, this syntax is not supported on Windows. So, I created a PR to use cross_env so it would also work on windows.

After addressing all the comments on my original PR (to create the new page UI), I helped Genne23v resolve CI failure on this PR. New code had been added that would check for an ENV variable value and crash if the environment was production and no value was specified. However, this should not have affected the end to end tests as the environment there was set to testing:

"start:e2e": "cross-env NODE_ENV=testing node --require
dotenv/config ./build/server.js",

This script starts the app when end to end tests are run. However, after some investigation and through this discussion, I found that there were two problems with this approach:

testing is not a valid value for NODE_ENV. Providing testing will result in NODE_ENV being set to production
During the build process, all calls to process.env.NODE_ENV in the code are replaced with the actual value for NODE_ENV. Thus, something like console.log(process.env.NODE_ENV) would become console.log("production"). This was done by the following script. Here, no value for NODE_ENV is given, and therefore production is assumed by default.

 "pretest:e2e:run": "cross-env SECRETS_OVERRIDE=1 run-s build"

Moving the override to this script and changing the value to test resulted in the CI passing again:

"pretest:e2e:run": "cross-env NODE_ENV=test SECRETS_OVERRIDE=1
run-s build"

More information about this process can be found in this discussion.

Starchart: Record Creation Page

Eakam — Mon, 20 Feb 2023 05:05:30 +0000

The past week, I have been working on creating the record creation page UI. This involves creating a form component that will be reused on this and the edit record page. A record has a name, type (A/AAAA/CNAME/TXT), value, and some other fields such as ports, course, and description, which provide context to the use of this record.
Originally, this page was called a domain creation page as mentioned in the issue. However, after some discussion on the PR, it was decided that it should really be called the record creation page

When I started creating this page, I wanted to make it responsive for all screen sizes. Since we are using Chakra UI for our page designs, this was pretty simply to do. It is possible to pass an array of values to a Chakra UI component prop for different screen sizes. For example, the following code changes the margin on the left based at different breakpoints (more details here):

<Container maxW="container.xl" ml={[null, null, '10vw']}>

This ensures that there is no margin on the left for smaller screens but keeps the margin on larger screens:

Large screens

Small screens

While Chakra UI's way to styling elements is really nice, I found that for some elements, I was repeating the same styles way too many times. For instance, these tooltip icons, which are used multiple times throughout the page:

<Tooltip>
  <InfoIcon color="#d9d9d9" fontSize="xl" />
</Tooltip>

While I could create another component for this, I found that it was possible to override global styles for specific elements using Chakra UI themes:

const theme = extendTheme(
  {
    ...
    styles: {
      global: {
        '.domain-form': {
          // InfoIcon
          '.chakra-icon': {
            color: '#d9d9d9',
            fontSize: 'xl',
          },
        },
      },
    },
  },
  ...
);

I found this a better alternative to copying the same styles all over the file, and without overriding the styles for that icon for all pages.

After finishing the form, I decided to write some end to end tests using Playwright for the form behavior. This was to test if the page redirected to the edit page after a record was created. The e2e test configuration runs the tests on multiple browsers, including mobile safari, and webkit. What I found was that the current sign in functionality was not working on safari. I checked the video of the failed test run and saw that the sign in button was clicked but no redirect happened.

While the current sign in functionality is supposed to be for testing and simply logs you in as a user (without any username or password), this could potentially cause problems in the future. So, I filed an issue to investigate this.

Starchart: Remix routes setup

Eakam — Sun, 12 Feb 2023 09:46:59 +0000

The past week, I worked on setting up basic user dashboard pages and routes for starchart. These routes involved pages for management, creation, and help for domains and certificates. The ideas was to setup a basic template, such as a heading, and the routes so these could be easily updated once the designs were finished.

Since starchart uses Remix, this was a straightforward process. Routing in remix can be configured by the file structure for the routes(more info here). So, I setup an initial folder structure for the difference pages:

app/routes/
  -- certificates/
    -- index.tsx
    -- instructions.tsx
    -- new.tsx
  -- domains/
     -- $domainId.tsx
     -- index.tsx
     -- new.tsx

This defined the following routes (in same order as above):

/certificates
/certificates/instructions
/certificates/new
/domains/:domainId
/domains
/domains/new

After creating a PR, I got a suggestion to add another component for the header that shows on these pages. So, I thought how I could show the header on all pages without including it everywhere. Initially, I created parent routes for the certificates and domains routes:

app/routes/
  ...
  -- certificates.tsx
  -- domains.tsx
  ...

These only served to include the header, and then rendered the children using the <Outlet />:

import { Outlet } from '@remix-run/react';

import Header from '~/components/header';

export default function DomainsRoute() {
  return (
    <div>
      <Header />
      <main>
        <Outlet />
      </main>
    </div>
  );
}

I got another suggestion to move it up another level so I would not have to include the header in two parent route files. I thought about moving it to the root file. However, this would mean that the header would also render on the login page, or more logic would need to be added to hide the header if the user was not logged in. I tried looking for a way to do this purely through the file structure, and found this helpful blog post.

To summarize, I added a pathless layout route for the index page, and placed my routes inside the __index directory. Thus, my routes would be children of the __index route (which does not have a URL and is simply the layout for these routes). The index page itself is also inside this directory. And since the login page is still separate, it is unaffected:

app/routes/
  -- __index.tsx
  -- login.tsx
  ...
  -- __index/
    -- certificate/
      -- index.tsx
      ...
    -- domains/
      -- index.tsx
      ...
    -- index.tsx

__index.tsx is the same as the previous parent layout routes:

import { Box } from '@chakra-ui/react';
import { Outlet } from '@remix-run/react';
import Header from '~/components/header';

export default function Index() {
  return (
    <Box>
      <Header />
      <main>
        <Outlet />
      </main>
    </Box>
  );
}

Starchart: Playwright and Chakra UI Setup

Eakam — Sat, 04 Feb 2023 04:38:53 +0000

The past week I worked on setting up Playwright, and Chakra UI with starchart. Chakra UI is needed so that their components could be used to build the web pages, and Playwright is to be used for end-to-end testing.

Chakra UI Setup

Setting up Chakra UI was relatively simple. I followed their instructions for the most part. I also found this example to be really helpful. My process for this went like this: I looked at the instructions in Chakra UI docs for the client, server and root files, and compared them with the existing code in starchart. Then, I also referenced them against the example code.

Not an ideal process to follow, but since I do not understand Chakra UI or Remix that well yet, I felt that this was the best way to do the setup. It worked, and I created a PR. Based on some feedback, I added some basic components (instead of using html tags) to the index page so some manual testing could be done.

Now, if you followed the PR link, you would have seen that it was merged but had a failing check. And that is what was addressed later while adding Playwright. Since the project was setup using the Remix blues stack, it shipped with cypress for end-to-end testing. The cypress folder had some tests but these were not modified when the app was setup since we intended to use Playwright. This resulted in the typecheck job failing, since it was also checking the cypress folder: tsc && tsc cypress

Playwright Setup

Setting up Playwright took longer than I had expected. First, I made a list of node modules that needed to be removed. These included cypress, @faker-js/faker, @testing-library/cypress, and eslint-plugin-cypress. These were only used by cypress so I uninstalled them using npm uninstall.

Next, I deleted the cypress folder, and the configuration file for cypress (cypress.config.ts). I installed playwright by using npm init playwright@latest, and following the prompts (docs). This also generated a config file for playwright, some simple tests in the specified test folder, and some more detailed examples of tests. I deleted the folder containing the examples since it was simply for reference, and added some basic tests.

For the configuration, I ended up using the defaults for most of the options. I also uncommented the configuration for mobile viewpoints, branded browsers, and output directory for test artifacts; and added the following based on some feedback:

baseURL: `http://localhost:${process.env.PORT}`
...
video: 'on-first-retry'

Setting a baseURl allows navigating to a page with a relative URL:

await page.goto('/');

The second configuration records a video of the test on the first retry after it fails.

Trying to Setup CI

So far, this process was pretty simple. Installing playwright also auto generates a GitHub workflow file. I tried adding a new job based on this auto generated file, and updated some npm scripts that were previously being used for cypress to run the tests. However, to run the tests, the app must be started. And to do that, the mysql database container must be running. I tried using the defined docker script, which uses docker-compose up -d to start the container but prisma db push failed with the following error:

I tried a bunch of things to try and fix this. I posted about this in Slack, and found out that mysql can take a while to start. So, I tried adding a wait before running the tests based on this discussion. However, this still resulted in the same error. I even tried doing prisma db pull before prisma db push. However, I got a different error this time:

This was really strange, since the database should have been setup. Still I did not know why this was failing.

Using Service Containers

Since I was basically out of ideas on how to fix this, I tried completely reworking the job by using a service container for mysql instead:

  E2E-Test:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    services:
      mysql:
        image: mysql:8
        ports:
          - 3306:3306
        env:
          MYSQL_DATABASE: starchart
          MYSQL_USER: starchart
          MYSQL_PASSWORD: starchart_password
          MYSQL_ROOT_PASSWORD: root_password

    steps:
    ...

And the tests worked! I am still not sure why they were failing before. Maybe docker-compose doesn't work with GitHub actions?
With this, I marked the PR ready for review, and the broken CI was fixed.

Starchart: release 0.1 planning

Eakam — Sat, 28 Jan 2023 04:58:08 +0000

This week, after some discussion, a plan was made for release 0.1 of starchart. This involved getting an initial app setup using Remix's blues stack so that people could code on top of it. Next step involved creating some issues which could be addressed in release 0.1 release 0.2 and some for further releases. As I am mostly focused on front-end and testing, I created the following issues:

The first three issues are the ones that I plan to address in the next few days for release 0.1, which would be next Friday. These could be done in any order but I think setting up Chakra UI with Remix should come first since this would allow the use of Chakra UI components for building the pages.

This could be followed by adding jest and playwright for testing. Part of this also involves removing any unneeded dependencies that the Remix blues stack comes with, such as Cypress, which is another end-to-end testing framework.
Adding a healthcheck route could also be done in release 0.1 or release 0.2. This would be a /healthcheck route that returns a 200 response with a message stating that the server is running.

The other issues would take longer to address. The user domain management page is supposed to be a page which allows users to view and manage their existing domains. This page also links to the domain creation page, which has a form to allow creation of new domains.

The admin dashboard would serve as a place for admins to view all the certificates, domains, and users. This also includes the ability to search and filter through this data, and update any records. Some aspects of the user dashboard could be reused for this page as well.

Adding these pages requires a design to be created first. One such issue is being worked on to create designs for user dashboard pages using figma (#36 Create user dashboard pages design).

Starchart: Picking a project area

Eakam — Sat, 21 Jan 2023 05:02:10 +0000

As we continue to work on developing starchart, which is a project that aims to make it easier to Seneca developers to create SSL certificates (without worrying about the costs or the need to provide personally identifiable information), a list of task groups has been created to make it easier to visualize the different parts of the project. These include Web, Testing, Server, DNS, etc. (full list here).

I have spent the last week thinking about where I can contribute. An obvious choice was Testing as I spent the previous week researching Playwright, which is a framework for end-to-end testing. As I looked into some of its features, I found that it has auto-wait functionality for its tests by default. Basically, before an action is performed on an element(e.g. click), it will wait for it to be in a specific state (e.g. attached to the DOM) based on the action. This reduces flaky tests which fail if a statement executes before the element is ready.

Further, through Codegen, tests can be automatically generated based on actions performed in the browser. This should reduce the time required for writing tests quite a bit. So, in addition to working on testing, I also decided to contribute to the Web component, which involves building the pages for the app. This will be done using Chakra UI and Remix. Chakra UI provides a bunch of components for different needs such as tooltips, cards, popups, and many more. I have worked on building webpages a lot in the past five months, and even though I have never used Chakra UI, I think I would still be able to utilize some of that experience here.

Finally, this is meant as a guideline, and not restrictions, for which parts of the project I would like to contribute to.