Conversation
federico-stacks
left a comment
There was a problem hiding this comment.
Just to refresh my memory. Do we want to keep just the Workflow run on release branches or also keep PRs/Worfklows against release branches?
| echo "Done" | ||
|
|
||
| ## Use the gh cli and API to delete caches that have existed for at least x days | ||
| ## - ignore caches with a key of `stacks-core-bitcoin-binaries` |
There was a problem hiding this comment.
nit: should this comment being revised due to the change introduced at line 139-140?
| # ## Filter out release branches | ||
| # | select(.head_branch | test("release/") | not) | ||
| ## Filter out release branches (include any PRs etc made against a release branch) | ||
| | select((.head_branch | test("release/")) and (.name | test("release/") | not) or (.head_branch | test("release/") | not) ) |
There was a problem hiding this comment.
qq: does or (.head_branch | test("release/") | not) overshadow (.head_branch | test("release/")) and (.name | test("release/") | not) ?
So that in the end deleting everything except workflows with "release/" literally in their name?
There was a problem hiding this comment.
yes - i beleive the second query you mentioned is just more verbose (i discovered the same after i had already tested the change).
since i want to redo some other things here, i'll re-test with the simplified logic
There was a problem hiding this comment.
So that in the end deleting everything except workflows with "release/" literally in their name?
had to refresh my memory here, but yes. what this means is that if you were to PR a change to a release branch, the workflow would be deleted after the set amount of time (30 days by default).
however, if the PR is fromrelease/xxx(like for the release -> develop PR), it's not eligible for deletion.
i think the ideal scenario here is: any release workflow triggered manually should be ignored, but any other workflow should be eligible. i'll see if i can adjust the query to accomplish that and re-open the PR later.
The nit i had was that release workflows were being cleaned, and i see value in keeping them around since they're related to published releases. |
|
converting this to draft to rework it based on feedback by @federico-stacks |
long running nit i had for the workflow cleanup job - it would delete release workflows and i think at a minimum those are worth keeping or at least keeping for much longer since stacks-core is released infrequently.
this change addresses that nit so it will not delete ci.yml workflows for a release.
after i tested this change though, i noticed another field in the actions json that i think might make the jq easier to read:
"event": "workflow_dispatch",so the filter i currently have of:
may be more easily written like:
untested, but i think it should work. alternatively, the more verbose select stmt proposed in this PR also would work.