Why not to run Weekly_Digest in last week

[yangwenmai]

https://github.com/talk-go/night/issues?q=is%3Aissue+is%3Aopen+label%3Aweekly-digest

In last week, the weekly_digest not to run.

[yangwenmai]

@abhijeetps

[TheSalesOpsGuy]

Bumping this as it went another week for me as well and didn't run the digest on Sunday as expected

[drdanz]

Same issue in my repository

It stopped for 2 weeks in march, then there was one more run, and then it stopped again, and at the moment it's still not running.

Maybe it is something related to the configuration file? Compared to the example, this difference could be important:

-publishDay: sun
+publishDay: 'sunday'

[abhijeetps]

Hey @yangwenmai , I am really sorry for the delayed reply.
I have been a little busy lately as I am now finishing up my Uni.
Well, this issue looks similar to what we have seen before. You can follow this thread: #65
This was causing big trouble, but I don't know somehow, without making any changes, it worked. 😅
The problem was most probably on the GitHub end. And they fixed it before and then it worked fine.
But looks like it's again causing trouble.
Weekly Digest App is mostly busy on Sunday, so, I would recommend you to change your publishDay in the config to some other day. 😄
Still, I will take a look at it before this month end. 😄

[abhijeetps]

@drdanz , the problem is not due to the configuration file. It will work fine for sun, sunday and 0 as well.
The problem is most probably on GH end as the bot makes a lot of requests on Sunday, especially.
I will recommend changing the publishDay to some other. I will take a look at it at the end of May. 😄

[C0ZEN]

@abhijeetps I could look to provide a PR adding an option to define a specific hour in the day for the release. This would allow consumers to still set the sunday for the report but at a more specific moment in the day. That way would reduce the large amount of requests at the same moment (this is not perfect at all but give more control on the first hand and could avoid this common problem). What do you think about that?

[abhijeetps]

@C0ZEN that would be really helpful if you can make the PR.
But I am concerned about another major thing.
What do we plan to do if the user hasn't added any configuration? According to the current default way, the app will run once every day and at anytime and will publish the digest, however, this will make the app publish many digests in the default case (when the config isn't defined.)
Still though, I would like to have some more discussion around it how you are planning to do that. 😄

[C0ZEN]

@abhijeetps
First of all, to avoid a breaking change, the default time should be the same as before (dunno what is it though but you can tell me).

Without checking the code and guessing, the behavior is this one:

• There is one digest per day
• The digest fetch all the projects to access the config file (and too much request break the feature?)
• If the config file match the day of the release notes, an issue is created
• If no config is found, the default is sunday

If you can confirm this and eventually add more information if you think that this could be helpful to this feature, let me know. Thank you

[abhijeetps]

@C0ZEN , there's no such thing as default timing for weekly digest at the moment.

I have used probot scheduler to trigger the app for a repository every 12 hours. The time in which probot schedular gets triggered for a repository is completely random in this 12 hours duration.
When the weekly digest is triggered, it first checks if the day today matches the publishDay of the repository (configured in .github/weekly-digest.yml or the default day (Sunday)), it then initiates the publication of weekly digest as in issue.
Additionally, I order to avoid duplicate weekly digest being published, I have added another another check to check if a weekly digest has been published in past 24 hours or not.

Thus,

First of all, to avoid a breaking change, the default time should be the same as before (dunno what is it though but you can tell me).

There is no such thing as default time. Sure there is exist a default day to publish the weekly digest day as Sunday.

There is one digest per day

Yes, it is.

The digest fetch all the projects to access the config file (and too much request break the feature?)

It's not that too much request will break the feature. I think publishing reducing this duration of 12 hour to exact timestamp or decreasing the duration might cause some unknown issue as the app publishes ~350 digests every week in public repositories (unknown for private repositories).

If the config file match the day of the release notes, an issue is created
If no config is found, the default is sunday

Yes, and yes.

Running the digest at a particular timestamp is a good idea, but I am not sure yet if this can be implemented at a timestamp for some case. Interested to see how you are planning to propose this idea.

[C0ZEN]

@abhijeetps
Probot scheduler is missing some features of the cron jobs and I was not expecting that.
As you said, the job will start like "after x hour do that" and it is not always exact.
This is the main problem for me and the feature I wanted to add.

Nevertheless I may have found a workaround with the GitHub schedule action which allow users to set their own cron job.
Using it seems a good solution - the weekly digest could be at a time of the user choosing besides no need to have necessarily a weekly digest anymore, it could be daily or whatever -.

Do you think that this could be the solution?

[Rory-Z]

Hi, guys
I added this robot to my project, but it only ran correctly in the first week, and it hasn't run since. I set publishDay: 'Monday', but it doesn't seem to work, what else can I do?
By the way, although this robot has only run once, I still like it very much. If it can run normally, it will be of great help to me

[TheSalesOpsGuy]

Do you think that this could be the solution?

Moving this to an action in general would be a huge ++ I think and would also allow for others to more easily fork and improve upon your amazing work so far

[C0ZEN]

@TheSalesOpsGuy I never create an action but I am willing to. And indeed an action is usually the next big step that most dev tend to use instead of Apps. Adding this should be then a new way of using this project meaning: no breaking change, no change required for existing configuration.
Still waiting approval/highlights from @abhijeetps, this is not a small task it seems.

[alexcnichols]

Encountering this as well. @abhijeetps - Is the server still running? Still hitting rate limiting issues maybe?

[bonniewolfe]

@abhijeetps Hi. its not working for me either and I changed my config to Monday and put it in a public repo after it did not run in my private repo on Sunday. I am going to keep moving it forward a day until it runs, but I am also going to write you from my other persona because I think the other me, might be able to offer you some support for making this more stable. - Bonnie Wolfe, Open Source Community Manager at MERL Center

[ExperimentsInHonesty]

@abhijeetps It's Bonnie Wolfe again. I run Hack for LA, which is the largest organized community of open source volunteers who work on projects for government and non profits at no cost. We also happen to have a site called https://100automations.org (work in progress), whose goal is to support open source projects like yours, by connecting their authors with other software engineers who can (as a group) respond more effectively when the applications start getting popular and scaling issues start to be evident and be responsive to support requests.

I think we can help reconfigure the tool so that it will keep running as more people use it. We have quite a bit of experience with this, through building a tool called True GitHub contributors, which is very GitHub API intensive. Additionally, it may make sense to allow people who want to install the app directly in their repo to do that, which might encourage more customization and eventual feature improvements being sent back to the main branch.

If you are interested, please reach out to me on LinkedIn or via email [email protected]