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

✨ Add new custom-cache-suffix option #239

Merged
merged 1 commit into from Nov 4, 2022

Conversation

jrfnl
Copy link
Contributor

@jrfnl jrfnl commented Nov 3, 2022

Description

As discussed in #234.

This adds a new custom-cache-suffix option to the action which allows for adding a custom addition to the cache key, which can be helpful to break out of outdated caches, especially when a project does not have a committed composer.lock file.

Fixes #234

Motivation and context

See #234

How has this been tested?

Both unit tests as well as integration tests are included with the PR.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

PR checklist

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING.md document.
  • I have added tests to cover my changes.

@jrfnl jrfnl requested a review from ramsey as a code owner November 3, 2022 20:30
Copy link
Owner

@ramsey ramsey left a comment

Choose a reason for hiding this comment

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

This is great. Thank you!

# via the first workflow which is run every Monday.
- uses: "ramsey/composer-install@v2"
with:
custom-cache-suffix: $(/bin/date -u --date='last Mon' "+%F")
Copy link
Owner

Choose a reason for hiding this comment

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

🎉

@ramsey
Copy link
Owner

ramsey commented Nov 3, 2022

Something about the cache_key_08.exp test is causing a failure, but I can't tell what it is yet.

As discussed in 234.

Includes tests.

Fixes 234
@jrfnl jrfnl force-pushed the feature/234-add-new-custom-cache-extra-key branch from d2954eb to 6f57711 Compare November 3, 2022 20:37
@jrfnl
Copy link
Contributor Author

jrfnl commented Nov 3, 2022

Something about the cache_key_08.exp test is causing a failure, but I can't tell what it is yet.

Windows and file permissions. Should be fixed now.

@jrfnl
Copy link
Contributor Author

jrfnl commented Nov 3, 2022

Hmm.. Composer v1 still giving trouble...

@jrfnl
Copy link
Contributor Author

jrfnl commented Nov 3, 2022

(which is weird as I had a passing build before I tidied up and rebased)

@jrfnl
Copy link
Contributor Author

jrfnl commented Nov 3, 2022

@ramsey As by now it's not the new test which is failing, could you restart the build just to check it wasn't some Composer hick-up ?

@ramsey
Copy link
Owner

ramsey commented Nov 3, 2022

Re-running

@codecov
Copy link

codecov bot commented Nov 3, 2022

Codecov Report

Merging #239 (6f57711) into v2 (7f9021e) will increase coverage by 0.02%.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##               v2     #239      +/-   ##
==========================================
+ Coverage   97.45%   97.47%   +0.02%     
==========================================
  Files           5        5              
  Lines         118      119       +1     
==========================================
+ Hits          115      116       +1     
  Misses          3        3              
Impacted Files Coverage Δ
bin/cache_key.sh 95.00% <100.00%> (+0.12%) ⬆️

@ramsey ramsey merged commit 83af392 into ramsey:v2 Nov 4, 2022
@jrfnl jrfnl deleted the feature/234-add-new-custom-cache-extra-key branch November 4, 2022 13:40
@jrfnl
Copy link
Contributor Author

jrfnl commented Nov 4, 2022

Right first round done: applied this in some 40 repos ;-)

For anyone looking for some more date-based example code:

      - name: Install Composer dependencies
        uses: ramsey/composer-install@v2
        with:
          # Bust the cache at least once every three months - output format: YYYYqQ, example: 2022q4.
          custom-cache-suffix: $(/bin/date +%Y)q$(( ($(/bin/date +%-m)-1)/3+1 ))

      - name: Install Composer dependencies
        uses: ramsey/composer-install@v2
        with:
          # Bust the cache at least once a month - output format: YYYY-MM-DD.
          custom-cache-suffix: $(date -u -d "-0 month -$(($(date +%d)-1)) days" "+%F")

      - name: Install Composer dependencies
        uses: ramsey/composer-install@v2
        with:
          # Bust the cache at least once a week - output format: YYYY-MM-DD.
          custom-cache-suffix: $(/bin/date -u --date='last Mon' "+%F")

@jrfnl
Copy link
Contributor Author

jrfnl commented Dec 8, 2022

Simplified version of the "once a month" code sample:

      - name: Install Composer dependencies
        uses: ramsey/composer-install@v2
        with:
          # Bust the cache at least once a month - output format: YYYY-MM.
          custom-cache-suffix: $(date -u "+%Y-%m")

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.

Better cache busting when using dependency-versions: 'highest'
2 participants