Skip to content

Feat/keep release jobs#92

Draft
wileyj wants to merge 3 commits intostacks-network:mainfrom
wileyj:feat/keep_release_jobs
Draft

Feat/keep release jobs#92
wileyj wants to merge 3 commits intostacks-network:mainfrom
wileyj:feat/keep_release_jobs

Conversation

@wileyj
Copy link
Contributor

@wileyj wileyj commented Dec 1, 2025

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:

| select((.head_branch | test("release/")) and (.name | test("release/") | not) or (.head_branch | test("release/") | not) )

may be more easily written like:

select((.head_branch | test("release/") | not) and ( .event != "workflow_dispatch" ))

untested, but i think it should work. alternatively, the more verbose select stmt proposed in this PR also would work.

@wileyj wileyj marked this pull request as ready for review December 1, 2025 20:24
Copy link

@federico-stacks federico-stacks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) )

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 from release/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.

@wileyj
Copy link
Contributor Author

wileyj commented Feb 5, 2026

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?

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.
i think i'll want to rework this logic slightly (and address your other comments) - i don't think we'll want to keep workflows from PR's against releases, just the manually triggered release workflow.

@wileyj wileyj marked this pull request as draft February 5, 2026 16:20
@wileyj
Copy link
Contributor Author

wileyj commented Feb 5, 2026

converting this to draft to rework it based on feedback by @federico-stacks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants