Workflow being disabled even though v2 is in use about keepalive-workflow HOT 7 CLOSED

@gautamkrishnar ,

I was wondering if the time_elapsed is taken into account by your action when using the api call?

If so, since @rfay's action uses 55 as time_elapsed and GitHub sends a warning before those 55 days, this could explain the behavior seen.
For info, last commit was on March 24 and March 24 + 55 days = May 18 (today).

Yesterday (and the day before because it was not yet 55 days after the last commit), we can see in the logs:
Nothing to do

Today, we see:
Kept repo active using GitHub API

But, then, I have other questions/remarks:

1. While 50 was a good default value for your v1 action (because it limits the number of dummy commits), why should we have such a default value with v2? I think 0 might be a good candidate. (In fact, I don't even think we should use this time_elapsed value and always make a call to the api, as I don't see what the problem could be with this).

2. The documentation on time_elapsed states: Time elapsed since the previous commit to trigger a new automated commit (in days) . Therefore, it is not mentioned that it will also be used to trigger the api call.

3. As there will be no further commits with the v2 api call, the "time elapsed since the previous commit" will not change. Does this mean that the api call will be made on each new workflow run? Or is the time elapsed since the last "keep alive" call taken into account?
   [EDIT]: Looking in another repo (using also time_elapsed = 55), I can see that the keep alive call is done on every run after 55 days. So, for me, this time_elapsed value is not necessary anymore, as, at the end, a repo with no commit will produce an api call every day.

Thanks

P.S: I forgot to mention that your action seems to work well inside a composite action (the same as the one used by @rfay).
In fact, we also have another repo that's still active even though there's been no new commit for over 60 days: https://github.com/ddev/ddev-redis-commander/actions/workflows/tests.yml

from keepalive-workflow.

@rfay this is an interesting use case. I haven't looked into this use case yet.

I mostly developed this action assuming that it's used directly in the repo that the action needs to keep alive. In this case https://github.com/rfay/ddev-drushonhost, I haven't thought about it being used under a nested action.

I will take a look at this when I get some time. Thanks for reporting it.

As a workaround, you can still just add gautamkrishnar/keepalive-workflow on https://github.com/rfay/ddev-drushonhost/blob/main/.github/workflows/tests.yml#L31 as the last step to keep it alive. Until I figure out what's happening in this case.

from keepalive-workflow.

@rfay i just released a release that outputs parent workflow's name when keeping it active.

Let's wait and see if the workflow is somehow getting disabled. If it's not feel free to close this jira.

from keepalive-workflow.

@julienloizelet time_elapsed is taken into consideration on v2 as well.

While 50 was a good default value for your v1 action (because it limits the number of dummy commits), why should we have such a default value with v2? I think 0 might be a good candidate. (In fact, I don't even think we should use this time_elapsed value and always make a call to the api, as I don't see what the problem could be with this).

My intention here was to call the API only when it's needed. It is not needed to call the API if the Last commit is not older than 60 days (or closer to).

If so, since @rfay's action uses 55 as time_elapsed and GitHub sends a warning before those 55 days, this could explain the behavior seen.

Thanks a lot for debugging it. I never knew this. Looks like setting a shorter time is OK. Thanks a lot for creating a PR to fix it. I will make 45 days as default for this project as well.

The documentation on time_elapsed states: Time elapsed since the previous commit to trigger a new automated commit (in days) . Therefore, it is not mentioned that it will also be used to trigger the api call.

Documentation needs some update. Thanks for noting it.

from keepalive-workflow.

@rfay I just checked. it should work just fine. From the action output i can see that the action is getting ran correctly and is producing a valid output:

https://github.com/rfay/ddev-drushonhost/actions/runs/9125279845/job/25091133605

The email you got might be most probably a GitHub Bug. I am not sure. It also looks like the scheduling is still working just fine in the repo. Lets wait for the deadline and see if the action is getting disabled or not.

I think I can add some more descriptive message about which file the action kept alive instead of just showing parent workflow. FIxing it right away.

from keepalive-workflow.

@all-contributors please add @rfay for bug and @julienloizelet for bug

from keepalive-workflow.

@gautamkrishnar

I've put up a pull request to add @rfay! 🎉

from keepalive-workflow.