Create nightly Github workflow to check for dead links

[carterworks]

Description

This creates a Github workflow that runs nightly at 1PM. In this workflow, there is a job that runs a program called lychee that scans all the code in the html, js and markdown files in the src, test, scripts and base directories for adobe.ly and experienceleague.adobe.com links. It then makes a small request to each of these links to see if they are still alive.

Essentially, it runs the following command

lychee --format=detailed --no-progress --include=adobe.ly --include=experienceleague.adobe.com {src,scripts,test}/**/*.{md,js,html} *.{md,js}

If there are any dead links (4xx or 5xx response codes), it will run the next job in the workflow, which uses the create-issue-from-file library to create a Github Issue that lists the links uses the craftech-io/slack-action library to post a message in the #alloy-ci Slack channel so that we may resolve them.

I chose to only look for adobe.ly links and experienceleague.adobe.com links to avoid the many Adobe internal, license, and example links that we have within our code.

I expect that the check will run in under 60 seconds.

Related Issue

PDCL-7744:

In February, a customer noticed that the link on the Alloy README was returning a 404. This is because the Alloy documentation moved from Adobe Developer's API documentation to the Experience League without a redirect being set up. While it's not too hard to fix, it would be nice to be able to get ahead of those link breakages before a customer see them. We should create either a single functional test or a suite of them that check the links in our code and documentation to see if they are still alive, in case things move again.

Motivation and Context

This will prevent customers stumbling across links that no longer point to the desired location, as happened in #808.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change which does not add functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA or I'm an Adobe employee.
• I have made any necessary test changes and all tests pass.
• I have run the Sandbox successfully.

[jonsnyder]

This is awesome! Great idea.

[jfkhoury]

Nice one @carterworks !

[carterworks]

Failing functional tests will be resolved when pull request #835 is merged