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
{{ message }}
This repository was archived by the owner on Aug 26, 2026. It is now read-only.
When I run npx jsr publish it uses the ohid connection between the repository and jsr for authentication. This mechanism is very clean.
By contrast with this repo I can't use the cli without an access token stored in the repo itself and the integration that attempts to automatically deploy from every push to any branch is very not desirable. Also, the fact that its trying to create an environment in my repo called Production is not cool.
It seems like the action in this repo is all custom code too rather than just a wrapper over the cli 🤔.
Personally what I was expecting from this:
The cli uses ohid when running in an action runner
There is an actual deployctl auth login command to establish a connection when running locally
The action is just a wrapper over the cli
There is a separate denoland/deploy-setup action which just installs the cli
There is a separate denoland/deploy-login action which just establishes either an oidc connection or can use an access token, etc.
There is a separate denoland/deploy action which which is a wrapper over the cli setup by the action above.
You do not attempt to configure my repo with Environments or pushes, specifically require an action, let the user pick which events trigger it.
When I run
npx jsr publishit uses the ohid connection between the repository and jsr for authentication. This mechanism is very clean.By contrast with this repo I can't use the cli without an access token stored in the repo itself and the integration that attempts to automatically deploy from every push to any branch is very not desirable. Also, the fact that its trying to create an environment in my repo called
Productionis not cool.It seems like the action in this repo is all custom code too rather than just a wrapper over the cli 🤔.
Personally what I was expecting from this:
deployctl auth logincommand to establish a connection when running locallydenoland/deploy-setupaction which just installs the clidenoland/deploy-loginaction which just establishes either an oidc connection or can use an access token, etc.denoland/deployaction which which is a wrapper over the cli setup by the action above.For example this would be pretty ideal: