Passing Authentication & Other Dynamic Files Between Jobs in GitHub Actions & Playwright

‍

In this blog post, we'll discuss how to pass authentication between jobs in GitHub Actions. While Global Setup in Playwright can be a useful feature, it can also become a bottleneck when sharding tests. 

‍

Instead, we'll show you how to use actions/upload-artifact@v3 and actions/download-artifact@v3 to pass data, such as storage state and other files, between jobs within the same workflow.

‍

It is worth noting that while passing the authentication token between jobs in GitHub Actions can be a useful strategy, we've ultimately come to the conclusion that when sharding in GitHub Actions it is often more efficient to simply log in and perform the setup tasks in the beforeeach block. 

‍

This may result in higher billable minutes, but in many cases the headache saved by avoiding the overhead of passing the authentication token between jobs outweighs the additional cost.

‍

That being said, there may be some situations where passing the authentication token between jobs is the best approach. We have two active projects we believe this solution works well for. As always, it's important to carefully consider the trade-offs and choose the strategy that works best for your specific use case.

‍

‍

Global Setup & Sharding

While global setup can be a useful tool for running automation on a single machine, it can become a costly bottleneck when running tests at scale. This is particularly true when sharding your tests across multiple machines, as each machine will need to run the global setup tasks independently.

‍

For example, let's say your global setup takes 6 minutes to run and you are sharding your tests across 20 different machines. In this case, the global setup tasks would be run on each machine, increasing your billable time by 120 minutes (20 machines * 6 minutes per machine). This can quickly add up, especially if you are running a large number of tests or have a high billable rate.

‍

Our Example

In the below workflow, we have two core jobs: setStorageState and useStorageState. The first job, setStorageState, is responsible for setting the storage state and uploading it as an artifact to be used by the second job. To do this, we use the actions/upload-artifact@v3 action, which allows us to upload a file or directory as an artifact that can be shared between jobs.

‍

The second job, useStorageState, depends on the setStorageState job and uses the actions/download-artifact@v3 action to download the storage state artifact. This artifact is then used to run the tests using Playwright. After the tests are complete, the useStorageState job also uploads the test results as an artifact using the actions/upload-artifact@v3 action.

‍

Example Code

‍

This workflow demonstrates how to use actions/upload-artifact@v3 and actions/download-artifact@v3 to pass data, such as the storage state, between jobs in the same workflow. By following these steps, we can efficiently set up and run tests that require a shared state across multiple jobs in GitHub Actions. This can be especially useful when running large scale test suites that require setting up a global state for multiple users.

‍

Removing Files

The Remove File action in this GitHub Actions workflow uses the rm action created by JesseTG, which allows for the deletion of a file at a specified path. In this case, the file being deleted is called "storage.json". This step is important because it clears out any existing files with the same name that may have been previously downloaded or generated during a previous workflow run.

‍

Deleting the file before downloading new files with the same name ensures that the workflow is always working with the most recent version of the file. If the file is not deleted before a new version is downloaded, it could cause conflicts or errors in the job, as the workflow may be trying to work with multiple versions of the same file at the same time.

‍

Additionally, if the file has sensitive information, keeping a outdated version may cause security concern.

‍

By adding this step to the workflow, it ensures that the job always starts with a clean slate and any previous versions of the file are removed before new files are downloaded or generated. 

‍

Conclusion

In summary, this blog post talked about ways to pass authentication and other dynamic files between jobs in GitHub Actions. We mentioned that while using global setup in Playwright can be handy, it can become a problem when you need to shard your tests. As an alternative, we suggest using actions/upload-artifact@v3 and actions/download-artifact@v3 to pass data like storage state and other files between jobs within the same workflow.

‍

We also acknowledged that passing the authentication token between jobs isn't always the best idea and it's important to choose the strategy that works best for you. The example workflow we shared gives you an idea of how to efficiently set up and run tests that require a shared state across multiple jobs by using artifact actions and removing unnecessary files that might cause issues.

‍

‍

‍