Baixar pinact 4.0.0 per a Windows

⚠️ Breaking Changes
#1540 Removed the -review option
Output SARIF and pass it to reviewdog. This has been announced previously.
pinact run -format sarif |
reviewdog -f sarif -name pinact -reporter github-pr-review
#1540 Always output diff
Even if you specify -diff=false, it is ignored.
#1540 -diff and -check are now aliases for -fix=false
This simplifies the logic, making it easier to understand and less prone to bugs.
#1540 -verify is now an alias for --verify-comment
-verify was unclear about what was being verified, so it has been renamed for clarity.
However, -verify is kept as-is to maintain backward compatibility.
#1458 #1558 Version comments are now required @ManuelLerchnerQC
For SHAs without a version comment, pinact automatically adds a version comment (validation error if -fix=false).
$ pinact run test.yaml
test.yaml:1
- - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
+ - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
Specifying a version comment makes it easier to see which version is being used, and makes it easier for tools like Renovate and Dependabot to update.
It also has security implications.
For GitHub Actions versions, you can also specify the SHA of a commit in a fork.
This means it could point to a malicious commit in a fork.
If you specify only the SHA without a version comment, you cannot tell whether it is the SHA of a commit in a fork.
By requiring version comments, you can verify that the version comment matches the SHA using the --verify-comment option.
Even if a fake version comment is added to a fork's SHA, it can be detected by --verify-comment.
An attacker could also create a tag pointing to a fork's SHA, but creating a tag requires write permission, which raises the bar for attacks, so this can be said to improve security.
Of course, this is only meaningful if you verify with --verify-comment, so it is recommended to run pinact with --verify-comment in CI.

Features
#1540 -no-api: support for offline validation
#1540 You can now check whether the version being used satisfies min age, not just newer versions
#1540 More flexible min age support via rules
#1540 #1542 #1543 Support for a global configuration file
#1435 Automatic correction of version comments via -verify-comment @ManuelLerchnerQC
#1547 #1552 #1557 #1562 -diff-file: limit pinact's targets to only the changed lines

-no-api: support for offline validation
If you just want to check whether something is pinned, you don't really need to use the GitHub API, but previously the GitHub API was called.
With the -no-api option, you can validate without calling the GitHub API.
However, since API calls are currently essential for fixing code (this may change in the future if caching is supported), you need to specify either -fix=false or -format sarif.
Implicitly treating it as -fix=false could cause behavior to change and become a breaking change when caching is supported, so it must currently be specified explicitly.

You can now check whether the version being used satisfies min age, not just newer versions
For example, you can run it in CI against modified lines to check whether any dangerous versions that do not satisfy min age are being used.
This is not checked by default, but is checked when you run pinact run --verify-min-age or pinact run -min-age <min age>.

More flexible min age support via rules
min age can now be configured in the configuration file.
Additionally, by using rules, you can apply settings such as min age to specific actions.
min_age:
value: 7 # default setting
rules:
# Allow latest for suzuki-shunsuke's actions
- ignore: true
conditions:
- expr: |
ActionRepoOwner == "suzuki-shunsuke" && ActionVersion == "latest"
# Set min age to 0 for actions/checkout
- min_age: 0
conditions:
- expr: |
ActionRepoFullName == "actions/checkout"
For rules, conditions are evaluated per rule, and the settings are applied if matched.
You can write multiple conditions, and the settings are applied if any one of the conditions matches.
expr follows https://expr-lang.org/docs/language-definition. Please read the documentation for details.
The settings of rules listed later in rules take precedence.

Support for a global configuration file
A global configuration file is now supported.
The file path is searched in the following order of priority:
1. $PINACT_GLOBAL_CONFIG
2. ${XDG_CONFIG_HOME}/pinact/pinact.yaml
3. ${HOME}/.config/pinact/pinact.yaml
On Windows:
1. $PINACT_GLOBAL_CONFIG
2. %APPDATA%\pinact\pinact.yaml
rules are prepended before the rules in the project configuration file.
So project settings take precedence over global settings.

Automatic correction of version comments via -verify-comment
If the SHA and the version comment do not match, the version comment is automatically corrected to match the SHA.
Previously, it would just return an error, but now it is automatically corrected.

-diff-file: limit pinact's targets to only the changed lines
If you specify a file in Unified Diff Format via -diff-file, you can limit pinact's targets to only the changed lines.
By passing the PR's diff file in PR CI, you can reduce unnecessary API calls and prevent corrections or errors from code unrelated to the PR's changes.
This makes it easier to introduce pinact via Required Workflow across an entire GitHub Organization of a large development organization.
To improve the overall health of a development organization, it is desirable to introduce pinact via Required Workflow.
However, if you suddenly introduce pinact as a Required Workflow in an Organization that has a lot of originally unpinned code, errors and corrections unrelated to the PR's changes will occur everywhere, causing confusion.
When errors occur in places unrelated to the PR's changes, the PR author thinks "what is this error?", "wait, do I have to fix this? It's unrelated to this PR so I want to split the PR, but creating a PR is a hassle."
It is also possible that the same error occurs in multiple PRs, and each one independently performs redundant fixing work.
Inquiries about errors come in from various teams, generating unnecessary costs.
If you try to fix everything before introducing the Required Workflow, it takes time to introduce, and during that time the bad situation continues where new unpinned code keeps increasing.
On the other hand, if you can fix and validate only the lines changed in a PR, the PR author can more easily accept making the fix, and there is no need to split the PR.
However, this alone does not pin existing code, so in parallel with this, you still need to run pinact against each repository and create PRs.
How do you generate the file specified by -diff-file? You can easily generate it using the action https://github.com/suzuki-shunsuke/pr-unified-diff-action.
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
persist-credentials: false
- uses: suzuki-shunsuke/pr-unified-diff-action@c932c1df5f577028d8ca05d2d3c0c059072d8821 # v0.0.1
id: diff
- uses: suzuki-shunsuke/pinact-action@pr/1065 # not released yet, will fix after release
with:
diff_file: ${{ steps.diff.outputs.diff_path }}