Tags: martimlobao/trunk-action
Tags
Overwrite annotations when running multiple trunk actions (trunk-io#266) See eslint/eslint#19065
Overwrite annotations when running multiple trunk actions (trunk-io#266) See eslint/eslint#19065
Fixes bundle for action.yml (trunk-io#249) Most important of the fixes is the first one, which sets `TRUNK_LAUNCHER_QUIET=false`. The launcher currently completely suppresses all output (including all errors), unless `TRUNK_LAUNCHER_QUIET` env var is set to `false`. ```bash if [[ ${TRUNK_LAUNCHER_QUIET} != false ]]; then exec 3>&1 4>&2 &>/dev/null fi ``` This prevents each and every one from debugging failed runs. Redirecting file descriptors like that also disables all `set -vx` output, resulting in a complete blackout and painful debugging. This PR will always enable launcher output, which is what I prefer, however if you don't like that, it may be changed, so that it's set only if `RUNNER_DEBUG == 1`. Also, you can migrate to `actions/download-artifact@v4` and rewrite this step: https://github.com/trunk-io/trunk-action/blob/03cb46f406176a84f390fb565960606c2bd0b8b3/action.yaml#L355-L378 --------- Co-authored-by: Eli Schleifer <1265982+EliSchleifer@users.noreply.github.com>
feat: make LFS checkout optional (trunk-io#260) Adds the option to disable LFS checkout either from services or as an input. Also, updates the registry for the docker image because docker tests were failing with permission issues Tested manually - tests here are failing for unrelated reasons.
[feat] add timeout and ability to cat debug logs (trunk-io#245) There may be times where the trunk action is unresponsive and is hung in CI. To understand whether this is a linter or trunk cli issue, we'll need logs to confirm. This PR adds the following optional inputs `timeout-seconds` and `cat-trunk-debug-logs` which will wrap the trunk check action with the unix `timeout` command should the user supply an argument for `timeout-seconds` Should the user specify `cat-trunk-debug-logs: true`, the trunk action will also cat out cli & daemon logs from `.trunk/logs/` Unfortunately, `timeout-minutes` doesn't work in `composite-actions` see actions/runner#1979 and https://github.com/orgs/community/discussions/50481 **Test Plan**: <details> <summary>End to End test to ensure timeout + logs work</summary> <img width="1873" alt="image" src="https://github.com/trunk-io/trunk-action/assets/31294356/27ca9a1b-fe54-4e73-928e-63625d1f934e"> </details> <details> <summary>End to End test to ensure timeout works </summary> <img width="1878" alt="image" src="https://github.com/trunk-io/trunk-action/assets/31294356/8fb7351a-11c0-4e83-9490-864c6ecdafc0"> </details> - [ ] Add Regression test (not entirely sure I can run this workflow) May need some help here!
fix: attempt to install specified pnpm version (trunk-io#243) Currently, we only install the latest pnpm version, which fails if the user has specified a pnpm version under `packageManager` in their package.json. This PR changes that to attempt to parse the version out of the package.json before defaulting to latest. The `pnpm/action-setup` action does have logic for parsing the version out of the package.json, but we cannot provide both an version and a version in the package.json, or it will fail ([source link](https://github.com/pnpm/action-setup/blob/master/src/install-pnpm/run.ts#L64)). Tested manually, both with and without the `packageManager` field.
feat: add option for Signed-Off-By line in upgrade action (trunk-io#238) Adds support for adding a `Signed-Off-By` line to commits created by the upgrade action, as requested [here](trunk-io/plugins#764). Tested in this repo, you can see the commit [here](trunk-io@cc7d39d).
feat: continue on node package install failure (trunk-io#236) ### Problem Currently, most of our check-on-prs/check nightly failures occur while installing node packages, for a variety of reasons. Right now, this causes the check to fail, and we report that "something went wrong". Instead, we may want to disable linters that depend on node-modules (specifically, stylelint and eslint) and lint the remaining files to report our best-effort results. Pros: - We would report some issues, and some issues is better than no issues - We wouldn't be erroring with a message that seems like an internal error (because for all we know right now, it could be) Cons: - A user could introduce a lint issue in the same PR as a breaking change to package.json and we would pass that PR - I am pretty sure that we don't have a great way of surfacing to the user that we're disabling eslint without writing an annoying amount of boilerplate to send the data through the cli through services back to github - We do log this in the action logs, but that's the most visible place ### Solution After talking with Sam about this, we figured the best solution is to disable the linters if we are auto-initing for the user, but not if the user has a trunk.yaml and therefore has deliberately opted to see ts/js issues. ### Testing Added a repo test for [prawn-test-staging-rw/node-packages-failure-test](https://github.com/prawn-test-staging-rw/node-packages-failure-test/tree/main) that has an invalid package.json, and checks to make sure the action disables eslint and stylelint, and continues after the failure.
add install action to install all trunk tools in trunk.yaml (trunk-io… …#234) install will pull trunk launcher from cloud into tmp location and then run the `trunk tools install` command. Optionally installs that are specified - else installs everything. Example of using it in flaky factory https://github.com/trunk-io/flake-factory/blob/main/.github/workflows/factory.yaml - name: trunk install uses: trunk-io/trunk-action@54ccfcf
Upgrade trunk to 1.21.0 (trunk-io#233) [](https://trunk.io) cli upgraded: 1.20.1 → 1.21.0 This PR was generated by the [Trunk Action]. For more info, see our [docs] or reach out on [Slack]. [Trunk Action]: https://github.com/trunk-io/trunk-action [docs]: https://docs.trunk.io [Slack]: https://slack.trunk.io/ Co-authored-by: TylerJang27 <42743566+TylerJang27@users.noreply.github.com>
PreviousNext