Nightly CI spews error notification to unrelated folks about puppetlabs-apt HOT 4 OPEN

Hey David :-)

I want to let you know we are working on this, apologies for any inconvenience caused. :-)

from puppetlabs-apt.

Thank you!

from puppetlabs-apt.

Hi David!

I'm looking into this, and I apologize for the long delay.

When I was looking at GitHub notification settings, I noticed that below the Subscriptions settings, there's a separate section called System, which has notification settings for Actions and Dependabot alerts. I noticed that my own settings had the Actions option set to "Notify me: Email. (Failed workflows only)." I wondered if yours might be set the same way, and if this might be why you're receiving these notifications?

from puppetlabs-apt.

Andrew from Perforce IT here.

I ended up diving into the docs for GitHub Actions, and found this. To quote from the page:

Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead. If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.

However, the behavior described in this quote doesn't quite seem to mesh with the behavior observed. The crontab entry was added to .github/workflows/nightly.yml in f90c737, but the user account associated with this operation appears to have been closed. The next user to modify this file was @DavidS with commit eb7ecf7. However, the next change to the cron entry wasn't until 3324549 when the quoting was changed (but not the value).

If I read the docs correctly, I believe the solution will be for a user to modify the cron entry to a different time, thus assuming ownership of the nightly testing process. I have heard that it is best not to schedule crontab entries for 'round' times(such as 0/15/30/45). This is because humans tend to pick those times and thus a large number of tasks all kick off at the same time. If an 'off' time (like 7 or 51) is picked, the cron entry will be fired when fewer jobs are being scheduled.

from puppetlabs-apt.