Update package manager index before installing ccache

[Chocobo1]

This is to avoid the index being outdated and failing ccache installation.

Relevant issues:
actions/runner-images#1757 (comment)
actions/runner-images#2924

From https://docs.github.com/en/actions/using-github-hosted-runners/customizing-github-hosted-runners:

Note: Always run sudo apt-get update before installing a package. In case the apt index is stale, this
command fetches and re-indexes any available packages, which helps prevent package installation failures.

[Chocobo1]

OK, I just found #1
IMO the point is someone has to update the package manager index anyway, either the user's workflow or this action.

Another way to handle this is to add a specific note about requiring the package manager is updated before using this action, however I think it is quite unnatural that an action which will install a package won't ensure the package manager index is up to date before installation...

[hendrikmuhs]

Not running apt-get update or any counterpart (e.g. brew update) is by design. It is highly likely that it has been run before, because C++ projects highly likely have other dependencies that need to be installed. Apart from that it is highly unlikely that an error happens due to a file removal in the upstream repository, ccache is rarely updated.

I agree that documenting this behavior would be nice. You could as well catch the potential error and print a meaningful message like: "did you run apt-get update / brew update before?"

If you desperately need this behavior I am ok with adding a parameter update-package-index to the action that if true runs the update. However the default false must be kept as this is the current behavior and many users rely on this and I don't want to change their workflow.

[Chocobo1]

It is highly likely that it has been run before, because C++ projects highly likely have other dependencies that need to be installed.

Right, but a part of the README is misleading about it:

NB! This should always come after the actions/checkout step.

This implies the user should run this action right after checkout and before installing the dependencies.
I'll leave the revising work for someone else...

However the default false must be kept as this is the current behavior and many users rely on this and I don't want to change their workflow.

I'm not particularly interested of adding an new option. You can also consider releasing version 2 of this action which will be a breaking change from v1 (accumulate with other breaking changes).

[Chocobo1]

Apart from that it is highly unlikely that an error happens due to a file removal in the upstream repository, ccache is rarely updated.

Maybe on ubuntu. On homebrew it is updated yesterday: Homebrew/homebrew-core@d0a04a5
And it has a few updates this year: https://github.com/Homebrew/homebrew-core/commits/d0a04a5229602f85ca7eb63a32a634d17f698191/Formula/ccache.rb

[hendrikmuhs]

It is highly likely that it has been run before, because C++ projects highly likely have other dependencies that need to be installed.

Right, but a part of the README is misleading about it:

NB! This should always come after the actions/checkout step.

This implies the user should run this action right after checkout and before installing the dependencies.

I don't read this, it only says it should it should be added after:

      - name: checkout from git
        uses: actions/checkout@v2

That's all, however I am currently not remembering the reason. I happily improve the docs, however I don't get the problem. It doesn't say anything else. The user feedback has been that most users run apt or brew update anyway, before this action. That's why an additional update unnecessarily increases build time. I haven't got any complains about it, I think it is the opposite: the existing user base will not appreciate this change.

That's why I am not accepting this change if it changes the current default behavior.

I'm not particularly interested of adding an new option. You can also consider releasing version 2 of this action which will be a breaking change from v1 (accumulate with other breaking changes).

For this change, I see no reason to change the default. I see quite some user base in public repositories and I imagine more in private repositories. I don't want to break existing workflows without a strong reason. The idea of a feature branch is a good one, however I wouldn't call it version 2 as long as it's experimental.

[Chocobo1]

That's why an additional update unnecessarily increases build time.

Like how much? < 30 secs at most is considered too much?

Anyway, thank you for your time.