You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GitHub Actions use the checked-out repo as the action source code. Currently, since we use Typescript, we need to transpile into Javascript and commit the transpiled code into the repo. This unhappy design choice forces us into a mechanism that violates a general principle not to commit generated or external files into a source repo. Why didn't they use packages instead, or maybe release attachments?
An improved mechanism would be to have the GH build workflow generate the transpiled code as part of the build, and then commit that (and only that) into a release branch. The Action version tag would then point to a commit on the release branch, which only includes transpiled code. This has quite a few benefits:
It keeps the main branch clean of generated code, which is good practice and simplifies code comprehension.
We can remove the Husky scripts that remind developers to build and commit the dist/ folder. They add considerable complexity and a dependency on Husky. It's never good to place requirements on the local development process.
We can also remove the automated build checks in the check-dist.yml workflow. These currently rebuild the dist/ directory, then compare against the committed code to validate they have been committed correctly. This has been flaky, especially if @vercel/ncc behaves differently between local workstation and server agent (this was a problem during development of the current workflows).
We could eliminate another dependency, and a complex one too - @vercel/ncc
There are also some potential downsides:
@vercel/ncc currently performs some tree-shaking or similar, and some minifying. If we get rid of it, the size of the repo (and the GH action download) would increase (think node_modules/). Perhaps we could preserve that part of the current mechanism and accept the dependency. If so, we need to continue to ensure that the tests are run against the generated runtime code.
At first sight it's a bit confusing to understand what is happening. The code that runs the action in a workflow isn't actually visible on the main branch, which is obviously the one you first see when you browse the repo. This had me puzzled for a while when I first discovered a repo that uses this mechanism (see below). It would certainly be worth mentioning it in the developers' README.
Example
An example of the proposed mechanism can be seen in tgymnich/publish-github-action. That repo is also useful as an action that could be used to implement the new mechanism.
The text was updated successfully, but these errors were encountered:
GitHub Actions use the checked-out repo as the action source code. Currently, since we use Typescript, we need to transpile into Javascript and commit the transpiled code into the repo. This unhappy design choice forces us into a mechanism that violates a general principle not to commit generated or external files into a source repo. Why didn't they use packages instead, or maybe release attachments?
An improved mechanism would be to have the GH build workflow generate the transpiled code as part of the build, and then commit that (and only that) into a release branch. The Action version tag would then point to a commit on the release branch, which only includes transpiled code. This has quite a few benefits:
It keeps the main branch clean of generated code, which is good practice and simplifies code comprehension.
We can remove the Husky scripts that remind developers to build and commit the
dist/
folder. They add considerable complexity and a dependency on Husky. It's never good to place requirements on the local development process.We can also remove the automated build checks in the
check-dist.yml
workflow. These currently rebuild thedist/
directory, then compare against the committed code to validate they have been committed correctly. This has been flaky, especially if@vercel/ncc
behaves differently between local workstation and server agent (this was a problem during development of the current workflows).We could eliminate another dependency, and a complex one too -
@vercel/ncc
There are also some potential downsides:
@vercel/ncc
currently performs some tree-shaking or similar, and some minifying. If we get rid of it, the size of the repo (and the GH action download) would increase (thinknode_modules/
). Perhaps we could preserve that part of the current mechanism and accept the dependency. If so, we need to continue to ensure that the tests are run against the generated runtime code.At first sight it's a bit confusing to understand what is happening. The code that runs the action in a workflow isn't actually visible on the
main
branch, which is obviously the one you first see when you browse the repo. This had me puzzled for a while when I first discovered a repo that uses this mechanism (see below). It would certainly be worth mentioning it in the developers' README.Example
An example of the proposed mechanism can be seen in
tgymnich/publish-github-action
. That repo is also useful as an action that could be used to implement the new mechanism.The text was updated successfully, but these errors were encountered: