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.
For example this would be pretty ideal:
name: Deploy
on:
release:
types: [published]
jobs:
deploy:
name: Deploy
runs-on: ubuntu-latest
environment: prod
permissions:
id-token: write # Needed for auth with Deno Deploy
contents: read # Needed to clone the repository
steps:
- name: Clone repository
uses: actions/checkout@v4
- name: Install Deno
uses: denoland/setup-deno@v2
with:
deno-version: v2.x
- name: Setup Deploy
uses: denoland/setup-deploy@v2
- name: Deploy Login
uses: denoland/login-deploy@v2
with:
organization: ${{ vars.DENO_DEPLOY_ORGANIZATION_ID }}
- name: Deploy
uses: denoland/deploy@v2
with:
project: ${{ vars.DENO_DEPLOY_PROJECT }}
entrypoint: main.ts
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: