🧪 Alternative Hosting is experimental, feel free to provide feedback if you encounter issues!

Example : Serverless Data Portal with Alternative Hosting

This repository is an example implementation of the @globus/template-data-portal.

You can create your own portal with similar functionality by following the Creating Your Own Research Data Portal section in the template repository and then referencing the sections below.

Background

When using our Serverless Portal Templates, your portal will be automatically deployed via GitHub Actions to GitHub Pages; for most implementations, this results in a simple way to quickly distribute a portal without having to manage infrastructure. However, our toolchain allows you to fully customize and control where your application is deployed.

Customizing the Built-In Workflow

The .github/workflows/static.yml is responsible for building your portal using the configured generator and configured content (e.g. static.json and content directory). Two modifications are required in order to utilize your own hosting mechanism:

1. Disable GitHub Pages Deployment
2. Add your own GitHub Action Job that uses the static-generated Artifact

Disable GitHub Pages Deployment

In your .github/workflows/static.yml, update the static workflow to include the input deploy_to_github_pages: false. This will signal to the workflow to not deploy the generated artifact to GitHub Pages.

yaml jobs: static: uses: from-static/actions/.github/workflows/static.yml@v2 with: deploy_to_github_pages: false

Add your own job that uses the static-generated Artifact

With the static workflow deployment disabled, you can now add additional jobs that utilize the generated artifact, including upload to your custom host.

There are a few important implementation details to consider when adding your own job:

• The static workflow produces an asset named github-pages.
  • Currently, the produced artifact is the result of actions/upload-pages-artifact@v3.
• Our Serverless Portal Templates use Next.js to export a static site. Their documentation on deploying a static export can be helpful when configuring your infrastructure to handle requests properly.

In the below example, a deploy job is configured to deploy the generated assets to Amazon S3.

yaml deploy: # Our deploy process requires the `static` job to complete first. needs: [static] runs-on: ubuntu-latest steps: # Download the artifact that was generated by the `static` job. - uses: actions/download-artifact@v4 with: name: github-pages # Extract the artifact... - run: mkdir artifact - run: tar -xf artifact.tar -C ./artifact # ...and deploy it to S3. - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::431478890660:role/globus_example-data-portal-alternative-hosting-action aws-region: us-east-1 - run: | aws s3 sync ./artifact s3://globus-serverless-data-portal-example

Common (Required) Changes to Configurations

When you update your portal to be deployed to an alternative host, there are likely configuration values in your static.json and Globus Application (when using Globus Auth for authentication) that will need to be updated to reflect your new (custom) host. Commonly, these configuration changes include:

• Updating your Globus Application Redirects to include your new host (e.g. https://{CUSTOM_HOST}/authenticate).