dprint / check Goto Github PK

Hi there!

This is slightly related to the discussion in #1: I believe the v1 tag should be moved to point to the same commit as the v1.6 tag. Similarly, l believe it's good practice to have a v2 tag that would point to the same commit as the v2.2 tag.

This would make it possible for people to track the v2 line of releases. This in turn will lead to less churn for the wider community. Currently, they can only track a single tag and they're all different:

The GitHub documentation describes this in a bit more detail.

GitHub actions can emit annotations which show up as notices/warnings/errors on the pull request. See the GitHub documentation.

It would be cool if dprint/check could emit them. I just checked the implementation of the action here and I see that it delegates directly to dprint check. Please let me know if you would prefer me to recreate this issue in the dprint repository.

Heya, this action has started failing with the following error

Error resolving plugin https://plugins.dprint.dev/rustfmt-0.6.1.exe-plugin@99b89a0599fd3a63e597e03436862157901f3facae2f0c2fbd0b9f656cdbc2a5: 

Error downloading https://plugins.dprint.dev/rustfmt-0.6.1.exe-plugin@99b89a0599fd3a63e597e03436862157901f3facae2f0c2fbd0b9f656cdbc2a5 - 404 Not Found 

Trying this link does indicate 404

https://plugins.dprint.dev/rustfmt-0.6.1.exe-plugin@99b89a0599fd3a63e597e03436862157901f3facae2f0c2fbd0b9f656cdbc2a5

As title. Need to break away from always needing to always do dprint check releases.

Our README instructs users to use dprint/check@v1 but the latest release is 0.1.0.

The chance of breaking changes to this action is quite small, so I'd say we can just create the v1 release to fix this.

Alternatively, we can also fix the documentation.

https://github.com/actions/cache#cache-action can be used to store the dprint cache in this check action, that radically lessens the load for the action.

As a minimal example: this setup is working nicely for me so far. I have yet to see if the intended behavior (clear cache on update to *dprint.json) is working, but that seems like the most logical thing to signal an update.

The question is, should this action itself allow for use of a cache, optionally? IMHO yes, but perhaps just the example of using the action should include a cache.