GitHub Actions Deployment
GitHub Actions is a hosted automation service provided by GitHub. It can run TrendRadar in the cloud with no server of your own. Whether runs use paid or included minutes depends on repository visibility and your account plan; this guide explains that choice when you create the repository.
Current task · GitHub Actions
Choose another methodRun the workflow in your own repository and receive the first message in your configured channel.
11 · Before runningConfigure one push channel
22 · Done whenNo log errors, and a test or first push arrives in the target app
33 · After it arrivesConfigure content and deliveryGet the project code
The difference between "Use this template" and "Fork"
GitHub offers two ways to copy someone else's project. For TrendRadar, you must use "Use this template", and not "Fork".
| Comparison | Use this template | Fork |
|---|---|---|
| Result | A brand-new, independent repository | A copy linked to the original project |
| Commit history | Not kept (a clean start) | Keeps the full history of the original project |
| Actions workflows | Enabled by default | Disabled by default (security restriction) |
| Use case | For your own use, no need to contribute back to the original project | You want to submit improvements back (Pull Request) |
| Recommendation | Recommended | Not recommended (may stop Actions from working) |
Forking may stop workflows from running
GitHub Actions is disabled by default on forked projects, and even after manually enabling it you may run into permission issues (see Issue #606). If you have already forked the project and run into problems, we recommend deleting the forked repository and recreating it with Use this template.
Steps:
Open the TrendRadar GitHub repository page
Click the green "Use this template" button
Choose "Create a new repository"
Enter your repository name (you can customize it, e.g. my-trendradar)
Choose the repository visibility
Public repositories can use standard runners without charge, but their files are public. Private repositories protect your config files but use the Actions minutes included with your account plan. Secrets are encrypted in either case.
Click "Create repository" to finish
Configure Secrets (push keys)
GitHub Secrets is GitHub's secure storage mechanism for keeping sensitive information that must not be made public (such as API keys, Webhook URLs, etc.). TrendRadar reads these Secrets to determine where to push messages.
Steps to add a Secret
Open repository settings
On your repository page, click the "Settings" tab at the top
Find the Secrets menu
In the left sidebar, expand "Secrets and variables" and click "Actions"
Add a new Secret
Click the "New repository secret" button
Fill in the name and value
Enter the Secret name in the "Name" field (it must match the table below exactly), and the corresponding value in the "Secret" field
Save
Click the "Add secret" button to save
Important notes about Secrets
- One Name per Secret: each key must be added separately. For example, Telegram requires two Secrets (TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID), so you need to click "New repository secret" twice and add them individually
- You can't see the value after saving: once a Secret is saved, GitHub hides its content, and you can only see the name and the last update time. This is normal security behavior, not a problem
- The name must match exactly: the Secret name must be exactly the same as listed in the table below (including case and underscores). Don't invent your own names, or the program won't be able to read them
- You can configure multiple channels: you can set up several push channels at once, and the program will send messages to all configured channels when it runs
- Updating an existing Secret: click the "Update" button next to the Secret, enter the new value, and save
Overview of all push channel Secrets
Not sure how to obtain a Webhook, token or chat ID? Open Push Channels first, then return here to add the matching Secret.
The GitHub Actions disk is discarded after each run. Basic pushes work without remote storage; for history and incremental detection, follow Storage Configuration and add all four required S3 credentials. Setting only the optional
S3_REGION above is not enough.Run the workflow manually
Once your Secrets are configured, you can trigger the workflow manually to verify that everything is set up correctly.
Open the Actions page
On your own repository page, click the "Actions" tab at the top. Be sure you are in your own repository, not in the original project (sansan0/TrendRadar).
Select the workflow
In the workflow list on the left, find and click "Get Hot News"
Trigger the run
Click the "Run workflow" button on the right side of the page, then click the green "Run workflow" again in the dropdown to confirm
Wait for the result
The workflow usually takes 2-3 minutes to finish. The page does not refresh automatically, so you can refresh it manually to check the run status
View the run logs
If the workflow fails or you want to see the detailed process, you can view the logs as follows:
Click a run record
On the Actions page, click the run record you want to inspect (it shows the run time and status)
View the Job list
Inside, you will see one or more Jobs; click the Job you want to inspect
Expand the steps
Each Job contains multiple steps; click any step to expand it and view its detailed log output
Verify with both logs and the actual message
A green workflow check only means the process completed; it does not guarantee delivery. Expand Run crawler, confirm there are no crawl, storage or notification errors, and check that the destination actually received a message.
The project's 7-day Check-In mechanism
This is a mechanism you must understand when deploying via GitHub Actions. If you're not aware of it, your automatic push may suddenly stop one day.
Why does the project insist on a 7-day Check-In?
TrendRadar follows a simple principle: use GitHub Actions responsibly, and never let abandoned scheduled jobs keep running and place needless load on GitHub's servers.
GitHub Actions provides limited, valuable public compute resources. The 7-day Check-In is not a GitHub-enforced limit or an attempt to add friction. It is a lightweight "I still use this" confirmation: active users renew periodically, unused jobs stop, and shared resources remain available to people who genuinely need them.
If you have not checked in for seven days, these updates may no longer be essential right now. A timely pause can also give you breathing room away from the information stream.
If you prefer not to check in manually, use Docker. Local runs also avoid this 7-day mechanism, but you must configure an operating-system scheduler yourself.
How is this different from GitHub's platform rule?
The 7-day period is a TrendRadar project rule.
Get Hot News checks its earliest visible run; once that run is more than 7 days old, it disables crawler.yml. This is not a 7-day GitHub platform limit.GitHub has a separate rule: scheduled workflows in public repositories may be disabled after 60 days with no repository activity, and scheduled runs may be delayed or dropped during high load. See the official GitHub schedule documentation.
What happens when it expires?
If the project's 7-day period has already expired:
Get Hot Newsis disabled and automatic pushes stop- Running
Check Inresets the timer but does not re-enable the crawler - After checking in, open
Get Hot Newsand click Enable workflow
How to check in
Go to the Actions page of your repository
In the workflow list on the left, find "Check In"
Click the "Run workflow" button
Click the green "Run workflow" in the dropdown to confirm
If Get Hot News is disabled, return to it and click "Enable workflow"
Check In clears Actions run history
Check In deletes the repository's Actions run history except for the current check-in run. That makes the next Get Hot News run start a new 7-day period. Review or save any logs you need before checking in, and check in weekly before expiry.
Change the run frequency (Cron schedule)
What is Cron?
Cron is an expression for setting up "scheduled tasks." You can think of it as setting an alarm clock: telling the system "at what time to automatically run a task." In TrendRadar, Cron determines how often news is fetched automatically.
A Cron expression consists of 5 numbers/symbols separated by spaces, representing, in order:
minute hour day month weekday
* * * * *
| | | | |
| | | | +-- day of week (0-6, 0=Sunday)
| | | +--------- month (1-12)
| | +-------------- day of month (1-31)
| +-------------------- hour (0-23)
+---------------------------- minute (0-59)
* means "every" */N means "every N" N means "at N"Common time presets
Time zone caution
GitHub Actions uses the UTC time zone (Coordinated Universal Time), which is 8 hours behind Beijing time (UTC+8). Conversion: Beijing time - 8 = UTC time. For example, if you want it to run at 8:00 Beijing time, set it to UTC 0:00. The table below already shows the converted results.
Steps to change it
Find the workflow file
In your repository, navigate to the file
.github/workflows/crawler.ymlEnter edit mode
Click the pencil icon (edit button) in the top-right corner of the file content, or click "Edit this file"
Find the cron configuration line
Find something like this in the file:
on:
schedule:
- cron: '0 */2 * * *' # 找到这一行Modify the cron expression
Replace the expression inside the quotes with the schedule you need (refer to the preset table above)
Commit the change
Scroll to the bottom of the page, fill in a description in the "Commit changes" section, then click the "Commit changes" button
Things to note when editing
- Don't modify anything other than the cron line; a wrong change may stop the entire workflow from running
- Don't delete the quotes on either side of the cron expression
- Setting it too frequently (e.g. once a minute) will quickly burn through your free GitHub Actions quota
- GitHub Actions cron triggers are not accurate to the second; the actual run time may be delayed by a few minutes
Enable AI analysis (optional)
If you want each pushed news item to include an AI-generated analysis summary, just add two more Secrets:
| Secret Name | Description |
|---|---|
AI_API_KEY | Your AI service API key (e.g. OpenAI, DeepSeek, etc.) |
AI_MODEL | AI model identifier (format: provider/model-name, e.g. deepseek/deepseek-v4-flash) |
They are added exactly the same way as the push channel Secrets. The AI feature is optional and does not affect the basic news push.