Move out the manifests into a separate repository to slow down with release cadence

[simonsan]

Hey, would it be possible to move out the manifests into a separate repository to slow down with release cadence? I'm using action digests + renovate and get a lot of PRs in different repositories due to a manifest update.

Do you think it would be worth, to choose a different architecture?
One where the manifests are not within this repository, so one where people can opt in to different releases (stable -> rebase on nightly every week/2 weeks?, nightly) which are different branches on that manifest repository.

This would make the action itself more stable WRT releases while we would still be able to get the latest software, if we would like to.

[taiki-e]

Managing on a digest basis is not the way we recommend (please read the readme) and doing what you suggest here, you lose the security benefits of managing on a digest basis, right? Why do you want to stick to digest basis management to that extent?

[taiki-e]

One where the manifests are not within this repository, so one where people can opt in to different releases (stable -> rebase on nightly every week/2 weeks?, nightly) which are different branches on that manifest repository.

If you want to do this, you can change the update interval in the update tool settings even with the current one, right?

[simonsan]

doing what you suggest here, you lose the security benefits of managing on a digest basis, right?
Why do you want to stick to digest basis management to that extent?
you can change the update interval in the update tool settings even with the current one, right?

Hmm, not sure.

I do think the problem is, that the updates to the action itself are tied to the updates of the package manifests and vice versa.

As a user, it would be nice to have a way to stay up-to-date regarding the action itself and the tool versions - but independently, so that maintaining a workflow using this action (with a digest) is less time intense.

[taiki-e]

Why are you using digest-based version management?

I know the guidelines that recommend it for security reasons (and in that case it is not always a good idea for the manifest to be automatically updated independently of the actions), but your use case seems different from that?

If the motive is reasonable, the proposal or alternatives can be considered; if it is unclear, nothing can be done (https://en.wikipedia.org/wiki/XY_problem).

[simonsan]

I use pinning for several reasons:

• have a deterministic workflow + better reproducibility
• to avoid breaking changes and have more stability
• security & explicitness

I would imagine it like:

- uses: taiki-e/install-action@56ab7930c591507f833cbaed864d201386d518a8 # v2.23.7
  with:
    manifest-version: ${{digest}} or ${{semver}}
    tool: [email protected]
    

This would lead to less frequent updates to the base action and would still let people pin their digests even on the versions. So base action semver and manifest version/digest would be decoupled.

[NobodyXu]

I think cargo-nextest repo also pins the version and lots of install-action updates PR

[simonsan]

I think cargo-nextest repo also pins the version and lots of install-action updates PR

Ah, interesting. Thanks!

https://github.com/nextest-rs/nextest/pulls?page=3&q=is%3Apr+is%3Aclosed+Update+taiki-e%2Finstall-action+digest

They had 58 PRs opened since Oct 3, 2023, so within 89 days or one every 1.5 days.

[taiki-e]

manifest-version: ${{digest}} or ${{semver}}

When versioning manifests, there are issues of automating manifest updates and their stability and incompatibility. How do you plan to address those? (Considering why you use digest-based version management, you need to pin manifest to the exact version, right?)

Can an external tool update it? If so, will they handle manifest and action compatibility issues correctly? For example, if the format of the manifest changes and the actions are updated correspondingly, the actions and manifest must be updated at the same time. (I have seen a similar problem in Rust, where users were confused about dependabot not handling such cases, and the issue was reported, and I guess the same problem exists.)

It is possible to reject incompatible manifests on the part of the action, but assuming such a problem exists, eventually, it could be more painful than the current one since someone would have to manually handle the update PR if it is rejected.

---

From the information submitted at this time, there is nothing that appears not to be addressed by reducing the frequency of install-action updates on the update tool (renovate?) side.

Since the actions themselves are rarely changed, reducing the frequency of action updates is virtually the same as reducing the frequency of manifest updates.

---

@NobodyXu

I think cargo-nextest repo also pins the version and lots of install-action updates PR

Well, in nextest, many more "update" PRs are opened other than install-action-related and almost all are automatically merged. The notifications may be noisy, but I'm not sure if that is actually a pain or not.

[taiki-e]

By the way, is one of the practical concerns with this approach that it would be more susceptible to rate limit? (I guess the source code tarball downloads and release binaries downloads sharing bandwidth?)

Performance depends on GitHub Actions, but may not be affected much because the action size will be smaller. (In the first place, the installation of supported tools is very fast.) If GitHub Actions' network is always stable...

[simonsan]

When versioning manifests, there are issues of automating manifest updates and their stability and incompatibility. How do you plan to address those? (Considering why you use digest-based version management, you need to pin manifest to the exact version, right?)

Let's take as an example the scoop installer, a PowerShell package manager for Windows.
This is their package repository for CLI tools: https://github.com/ScoopInstaller/Main

- uses: taiki-e/install-action@56ab7930c591507f833cbaed864d201386d518a8 # v2.23.7
  with:
    manifest-version: ${{digest}} or ${{semver}}
    tool: [email protected]

In the above scenario, someone has their action pinned to the digest. manifest-version could now be one of three things:

• rolling => https://github.com/ScoopInstaller/Main/tree/master/bucket
• digest=1e6870a813d148088e8cc190604c717acd17d47c=> https://github.com/ScoopInstaller/Main/tree/1e6870a813d148088e8cc190604c717acd17d47c/bucket
• semver or calver

So I would pin both like this:

- uses: taiki-e/install-action@56ab7930c591507f833cbaed864d201386d518a8 # v2.23.7
  with:
    manifest-version: 1e6870a813d148088e8cc190604c717acd17d47c
    tool: [email protected]

If there is a newer version of cargo-hack in this manifest repository, I have it pinned to 0.5.z. So newer versions don't affect me, even if they are available within the manifest repository.

EDIT: The other questions I need to answer later!

[NobodyXu]

Well, in nextest, many more "update" PRs are opened other than install-action-related and almost all are automatically merged. The notifications may be noisy, but I'm not sure if that is actually a pain or not.

I think it's certainly a bit noisy if you pinned the version of install-action, though for other use cases where you just specify a major version it works just fine.

I think maybe we can have a dedicated branch for storing manifest and store the minimum version required in the branch name?

E.g. branch name "manifest-v1.0.3" would only be available for version >=v1.0.3 and install-action should always picks the latest version, unless overriden bybuser.

We can also add other semver ops to the branch name, e.g. ">=v1.0.3,<1.7"

[taiki-e]

Let's take as an example the scoop installer, a PowerShell package manager for Windows.
This is their package repository for CLI tools: https://github.com/ScoopInstaller/Main

How would manifest-version updates be automated in that case? If it cannot be automated, then the tools installed will remain out of date. And if so, how is this different from pinning this action to an older version and excluding it from the update tool?

---

Also, unless there is a reasonable response to the following question, there is no possibility of accepting this proposal:

One where the manifests are not within this repository, so one where people can opt in to different releases (stable -> rebase on nightly every week/2 weeks?, nightly) which are different branches on that manifest repository.

If you want to do this, you can change the update interval in the update tool settings even with the current one, right?

From the information submitted at this time, there is nothing that appears not to be addressed by reducing the frequency of install-action updates on the update tool (renovate?) side.

Since the actions themselves are rarely changed, reducing the frequency of action updates is virtually the same as reducing the frequency of manifest updates.

Otherwise, as already mentioned, I will close this issue as I feel this is a proposal to reduce the stability and security of the project which is currently using this action on a digest basis.

[simonsan]

I actually worked around it by just closing all the PRs regarding install-action when they come up or ignoring updates to the action all together. Sometimes I leave PRs with digest updates open and ignore them as long as possible, to not be spammed any more. And when I have time to look into them or some actions break because of outdated versions, I look into the digest first and see if there has been updates to the tools being used. Then I merge one. Restarting the endless loop. :D

For now, I accepted it, that the changes to the install-action ecosystem would be too big. Maybe there will come up better ideas to fix this issue in the future to make using digests and updates a better user experience. So I'm fine with it being closed, actually.

[taiki-e]

Um, I've questioned this from the beginning, but doesn't Renovate support changing the update interval?

Even Dependabot, which is known for its poor functionality, supports it, so I thought Renovate also supports it...
(FWIW, Dependabot supports multiple update intervals (daily, weekly, monthly) and grouped updates of GitHub actions, e.g., cross-rs/cross#1460)

[taiki-e]

Even Dependabot, which is known for its poor functionality, supports it, so I thought Renovate also supports it...

Many of my comments were based on the assumption that your update tool supported such a very basic functionality to work as an update tool, and I was wondering about your motivation for making big changes to this action rather than using that functionality.

If the Renovate does not support it, then I can understand your frustration. However, I still think the right place to solve that problem is on the update tool (Renovate) side, not here.

[taiki-e]

I have checked the Renovate documentation and they seem to support scheduling.
https://docs.renovatebot.com/configuration-options/#schedule

The schedule option allows you to define times of week or month for Renovate updates. Running Renovate around the clock can be too "noisy" for some projects. To reduce the noise you can use the schedule config option to limit the time frame in which Renovate will perform actions on your repository. You can use the standard Cron syntax and Later syntax to define your schedule.