Rewrite without TypeScript compilation about actions HOT 9 OPEN

That is certainly one option for them. Some are also okay with pinning a commit hash, which tools like Renovate can update automatically without internalizing the dependency.

from actions.

Having the compiled code here is a compliance requirement for orgs that want to know what they are running.

This is largely why github wants this.

Additionally, you can make use of release-please to automate regenerating the compiled code stored in the repo.

Rewriting it without TS is a pretty big mistake as you can't use JSdoc to typecheck the code in automation.

Not sure why you'd want to reduce quality assurance.

from actions.

I have generally dealt with this sort of problem by using pre-commit. Here is an example of a hook that automatically compiles via Yarn. Is there a way to perform static type checking when using JSDoc?

from actions.

I misunderstood how JS Actions function. The bundling is unavoidable due to the dependencies needing to be bundled into a single JS file.

I would like to explore publishing the compiled scripts to the GitHub Release and pulling them in the root scripts as per this example with Golang binaries, but with the compiled JS scripts: https://full-stack.blend.com/how-we-write-github-actions-in-go.html#small-entrypoint-scripts

from actions.

You are correct that the dependencies need to be bundled for a JavaScript GitHub Action to function properly; we had the same confusion initially.

We have been happy with the approach GitHub Actions recommends in ScribeMD/docker-cache. Blend Engineering hints in the article you linked that they would have gone that route if their team hadn't objected to using JavaScript:

Our approach of using prebuilt binaries is the same idea in spirit as the recommended approach for JavaScript actions. For JavaScript actions, it is recommended to use the ncc compiler to create a single index.js file. With this single file entrypoint, the action just executes that file without any other setup necessary. Since Go is a compiled language, there is no direct equivalent of the “I have some source code and an interpreter” Node.js approach, hence the need for including prebuilt binaries. Interestingly enough, the ncc project lists the Go compiler as one of its motivations, so there must be something there!

We use pre-commit to automate as many steps as possible so contributors don't have to be familiar with our project or GitHub Actions. Dev environment setup takes about 5-10 minutes, and I am confident that investment is quickly paid back many times over by the benefits of running CI pipeline locally, including formatting, building minified JavaScript actions, running tests, auditing dependencies for known security vulnerabilities, automatically checking for copy/paste and spelling violations, and much more. Each local run of our CI takes about 1-2 minutes, and is triggered automatically by Git commits and pushes, which means faster dev cycles, less hassle, and less waiting. We also offer a GitHub Action that optimizes pre-commit performance, so a typical run takes about 5-7 minutes in CI on GitHub-hosted dual-core runners.

from actions.

I don't need to be convinced of using pre-commit style tools for these pre-push compilation process.

The thing I am not a fan of is storing compiled (JS bundled or Go) artifacts in the git tree. Whether GitHub recommends it or not, it's not ideal usage of Git. Bundled/Compiled artifacts should be treated like release artifacts. Changing to that type of model would restrict usage purely to the published artifact versions instead of being able to reference git commit SHAs or branches, so there are tradeoffs.

I will be making further updates to this repo shortly with changes to the contribution process with git-hooks etc. But not necessarily to the TS compilation.

from actions.

Yeah, I get that; "not ideal usage of Git" is a great way to put it. I expect many organizations would be unable to use this action if it were to execute downloaded code though. One well-established compromise is only committing the compiled JS to specific release branches that contain nothing else.

For whichever steps you feel pre-commit hooks are appropriate, part of the reason I'm advocating our specific pre-commit toolchain (beyond my obvious biases as its primary author) is that it already has first-class support for asdf, including the optimization proposed in #442.

from actions.

I expect many organizations would be unable to use this action if it were to execute downloaded code though.

In my experience companies with those types of restrictions would run a Docker build and push to their internal container registry, instead of referencing a v2 type of version which changes under their noses.

from actions.

Yeah, so I think I will rewrite these without TS, but still need to compile into a single file for publishing. So I might not change the publishing model anytime soon. I was just linking that Golang approach for future purposes.

from actions.