Hey everyone, I've been tasked with setting up a system to generate and email PDF reports to clients on a schedule. Think weekly usage stats or monthly invoices. I'm comfortable with the basics of CI/CD and using Docker, but I'm unsure about the best way to orchestrate the whole flow.
My initial plan was to write a Python script that generates the PDF, then use a GitHub Actions scheduled workflow to run it and send the email. But I'm hitting some questions:
1. Where do I securely store client email addresses and SMTP credentials? Environment secrets in the CI platform?
2. How do I manage the generated PDFs? Should I just create and email them in the same job, or is it better to store them somewhere (like an S3 bucket) first for auditing?
3. What's a common pitfall with timezones and schedules in CI/CD schedulers?
Here's a super basic example of the GitHub Actions workflow I was sketching:
```yaml
name: Scheduled Report Delivery
on:
schedule:
- cron: '0 8 * * 1' # Every Monday at 8 AM UTC
jobs:
generate-and-send:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Generate and Send Report
env:
SMTP_PASSWORD: ${{ secrets.SMTP_PASSWORD }}
run: python scripts/generate_report.py
```
Is this approach too naive? Should I be looking at a dedicated tool or maybe using something like Kubernetes CronJobs instead for more reliability? Also, how do you handle failures in this kind of pipeline—if the email fails, do you retry?
Learning by breaking
Yeah, your GitHub Actions approach is a solid starting point for something low-volume and internal. For the secrets, definitely use GitHub's environment secrets or repository secrets. Storing client emails there is okay for a handful, but if your list grows, you'll want a proper database or a config file pulled from a secure store.
On your second point about PDF storage, I'd push for saving to S3 or similar first, even if you email immediately. It gives you a backup if the email fails and a clear audit trail. You can just log the object URL. The pitfall with timezones in CI/CD schedulers? They usually run in UTC, so your cron `'0 8 * * 1'` is 8 AM UTC Monday. If your clients are in different time zones, you need to either adjust the cron schedule or, better, have your script calculate "Monday" based on the client's locale before generating. It's a common headache.
Your workflow sketch is missing the actual send step. You'd probably use a Python action with a script that uses smtplib and email libraries, pulling secrets as env vars. Just watch out for GitHub Actions' 6 hour max run time for scheduled jobs - if your PDF generation is super heavy, you might hit that limit.
ship it
Agree on S3 for audit. The 6-hour limit is key though. If you're generating for hundreds of clients with complex reports, even a few minutes per PDF can blow past that.
I'd add a warning about the email step itself. SMTP from GitHub Actions can get flagged as spam. You might need a dedicated sending service like SendGrid or SES, not just a raw `smtplib` call.
> have your script calculate "Monday" based on the client's locale
That's the right move, but then your cron just triggers the script daily. Let the script handle who gets what today based on a client config.
Benchmarks don't lie.
The spam warning is a really good point I wouldn't have considered. Even with a dedicated sending service, if you're sending a high volume of identical-looking automated PDFs from a shared IP, you might still run into deliverability issues, right? I'm curious if adding simple personalization, like the client's name in the subject line, would help at that scale, or if you'd need a more sophisticated warm-up strategy for the sending domain.