Deploy lane: mint the no-access identity token and give the resolver a source for it
- Dominant language
- Dockerfile
- Stars
- 1
- Forks
- 9
- Avg merge
- 9h 23m
- Merged PRs (30d)
- 58
Description
### Problem
The entitlements acceptance suite cannot run in the lane. Its Prove step fails at resolve ([run 34559415383](https://github.com/danielscholl-osdu/entitlements/actions/runs/34559415383)):
```
error: ENV_NOT_READY: unresolved required bindings: NO_ACCESS_USER_TOKEN
```
Every acceptance suite built on `os-core-test` reads `_TOKEN` for each user type it declares in `required-roles.json`. Entitlements declares `PRIVILEGED_USER` and `NO_ACCESS_USER`. Storage, search, and the other services with negative-path tests will declare the same two.
### Cause
The lane mints one bearer, as the deploy identity, and passes it as `RESOLVER_TOKEN` (`validate.yml`, "Mint test caller"). `resolve.py` has one `token` source that reads only that variable. There is no way for a descriptor to ask for the no-access identity's bearer, even though the stack mints it (`spi token --no-access`) and `spi onboard` already writes a federated credential for the fork on the no-access identity.
### Required change
1. Add a `noAccessToken` source to the resolver, read from `RESOLVER_NO_ACCESS_TOKEN`, with the same rules as `token`: no `default`, no `value`, empty counts as unset.
2. In "Mint test caller", log in as the no-access identity with `deploy_identity.no_access_client_id` from the facts and mint a second bearer for the same audience, masked and exported as `RESOLVER_NO_ACCESS_TOKEN`. The login must not replace the deploy identity's session, since Borrow and Restore run after it.
3. Extend the schema, the resolver README, the service descriptor runbook, and ADR-040's source table.
4. Update the entitlements descriptor example once the source exists: `NO_ACCESS_USER_TOKEN: { source: noAccessToken }`.
The stack side of this, making the no-access identity a member of `users` and the service user groups so it matches what `os-core-test` calls `NO_ACCESS_USER`, is tracked on osdu-spi-stack.
Contributor guide
Research direction
Start with resolve.py and the existing token source, then trace the "Mint test caller" step in validate.yml and the referenced deploy_identity facts. Review the schema, resolver README, service descriptor runbook, ADR-040 source table, and entitlements descriptor example. Done means the no-access source resolves from its masked lane variable without replacing the deploy session, and the acceptance suite can resolve NO_ACCESS_USER_TOKEN.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, python
- Domain
- ci-cd, devops, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100