search

puppetlabs / puppetlabs-apt

Puppet module to help manage Apt
https://forge.puppetlabs.com/puppetlabs/apt
Apache License 2.0
216 stars 462 forks source link

Nightly CI spews error notification to unrelated folks #1134

Open DavidS opened 9 months ago

DavidS commented 9 months ago

Describe the Bug

I'm getting CI notifications for failures in this repo.

2023-09-25_09MS+0200_1574x817

Expected Behavior

I'm not getting CI notifications for this repo.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Get hired by Reductive Labs in 2014
  2. Get autosubscribed to all repositories by IT.
  3. Do lots of great shit.
  4. Quit
  5. ???
  6. Get notifications for stuff I'm not responsible anymore.

Additional Context

I've already looked at the notifications settings on this repo and it is the default of "Participation and @mentions".

Here's a full notification email for tracing this on your end: [puppetlabs_puppetlabs-apt] Run failed nightly, Attempt #3 - main (a6db503).zip

pmcmaw commented 9 months ago

Hey David :-)

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

DavidS commented 9 months ago

Thank you!

njbrubaker commented 8 months ago

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?

ablackrw commented 8 months ago

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.