Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify cache cleanup actions #129

Merged
merged 1 commit into from
Sep 11, 2024

Conversation

WeiqunZhang
Copy link
Member

In our old approach, a workflow file contains a job that uploads the PR number as an artifact. While the PR is still open, the workflow_run triggered by it will download the artifact and use the information to clean up all except the last used cache associated with that original workflow. When a PR is merged or closed, there will be a post-pr workflow that uploads the PR number as an artifact and triggers a workflow_run that clean up all caches associated with the PR. The reason we did it this way was in the cache cleanup workflows, we did not find an easy way to get the number of the PR triggering them. This is not convenient because we have to add jobs uploading artifacts to workflow files.

After some experiments, we have found a reliable way to find the PR number without using artifacts. The workflow_run's payload always contains the head SHA of the commit that triggers it, whether the PR comes from a fork or not. We can then use gh pr list to search for that head and obtain the PR number.

In our old approach, a workflow file contains a job that uploads the PR
number as an artifact. While the PR is still open, the workflow_run
triggered by it will download the artifact and use the information to clean
up all except the last used cache associated with that original
workflow. When a PR is merged or closed, there will be a post-pr workflow
that uploads the PR number as an artifact and triggers a workflow_run that
clean up all caches associated with the PR. The reason we did it this way
was in the cache cleanup workflows, we did not find an easy way to get the
number of the PR triggering them. This is not convenient because we have to
add jobs uploading artifacts to workflow files.

After some experiments, we have found a reliable way to find the PR number
without using artifacts. The workflow_run's payload always contains the head
SHA of the commit that triggers it, whether the PR comes from a fork or
not. We can then use `gh pr list` to search for that head and obtain the PR
number.
@WeiqunZhang WeiqunZhang enabled auto-merge (squash) September 5, 2024 16:21
@WeiqunZhang WeiqunZhang merged commit d792c63 into AMReX-Fluids:development Sep 11, 2024
12 checks passed
cgilet added a commit to cgilet/incflo that referenced this pull request Sep 12, 2024
commit d792c63
Author: Weiqun Zhang <[email protected]>
Date:   Wed Sep 11 10:07:00 2024 -0500

    Simplify cache cleanup actions (AMReX-Fluids#129)

    In our old approach, a workflow file contains a job that uploads the PR
    number as an artifact. While the PR is still open, the workflow_run
    triggered by it will download the artifact and use the information to
    clean up all except the last used cache associated with that original
    workflow. When a PR is merged or closed, there will be a post-pr
    workflow that uploads the PR number as an artifact and triggers a
    workflow_run that clean up all caches associated with the PR. The reason
    we did it this way was in the cache cleanup workflows, we did not find
    an easy way to get the number of the PR triggering them. This is not
    convenient because we have to add jobs uploading artifacts to workflow
    files.

    After some experiments, we have found a reliable way to find the PR
    number without using artifacts. The workflow_run's payload always
    contains the head SHA of the commit that triggers it, whether the PR
    comes from a fork or not. We can then use `gh pr list` to search for
    that head and obtain the PR number.

commit a007c21
Author: Candace Gilet <[email protected]>
Date:   Wed Sep 11 16:57:56 2024 +0200

    Fix case of multiple tracers with default initial conditions. Issue (AMReX-Fluids#132)

    introduced in PR#131
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