Replaced op env ls with process.env + regex

[1password-rahul]

Reason To Be

This PR aims to remove the repository's dependency on the op env command. This is part of an effort such that we can eventually use the command in the 1Password CLI in relation to the Environments feature.

Thought Process

I chose to replace the op env ls command with Node's standard process.env in the function getSecretReferenceEnvNames(), filtering to any secrets that follow the secretReferencePattern. I used regex to define this pattern and ensure that the same variables are picked up by process.env as op env ls. I compared the pattern against op env ls (CLI 2.40.0) on edge cases (sections, query params, whitespace, malformed and multi-line values), and both select the same variables. read.parse still validates each reference and fails the action on errors.

Possible Impacts

In this implementation, no await statement is needed, so loadSecrets is no longer an async function - as a result, any references to the function no longer have the await keyword. I also had to edit the tests to account for the usage of process.env over the op command. @actions/exec is also not needed anymore, so it was removed from utils.ts, utils.test.ts, config/jest.config.js, package.json, and package-lock.json. actions-exec.ts was deleted.

How To Test

Can simply run npm test - make sure to check the tests that were changed as well. The E2E Tests workflow on this PR runs the action with a service account and Connect against real secret references, including OP_ENV_FILE and SSH keys.

[tinaxcodes]

Thanks for this! The refactor is clean and the e2e runs look good. Requesting one change before merging: the new pattern doesn't quite match what op env ls selected.

My understanding is that op env ls only accepts the characters allowed by the secret reference syntax. The new regex only excludes /, newlines and non-ASCII, so it now matches values that were previously skipped, for example:

• op://My Vault/item (old)/pw
• op://vault/item@x/field
• op://vault/item/field#1
• values containing a tab

These now reach read.parse, and if op read rejects them the whole action fails, where before they were silently ignored. In the other direction, op://vault/item//field (empty section) used to be listed and is now skipped.

Could you switch the pattern to an allow-list matching the documented syntax (assume the documented syntax is still valid), and add a table test covering these cases?
Also while you're there, extractSecret passes the untrimmed value to read.parse even though the filter checks value.trim(), so trimming in one place would keep the two consistent.

[1password-rahul]

Thanks for this! The refactor is clean and the e2e runs look good. Requesting one change before merging: the new pattern doesn't quite match what op env ls selected.

My understanding is that op env ls only accepts the characters allowed by the secret reference syntax. The new regex only excludes /, newlines and non-ASCII, so it now matches values that were previously skipped, for example:

• op://My Vault/item (old)/pw
• op://vault/item@x/field
• op://vault/item/field#1
• values containing a tab

These now reach read.parse, and if op read rejects them the whole action fails, where before they were silently ignored. In the other direction, op://vault/item//field (empty section) used to be listed and is now skipped.

Could you switch the pattern to an allow-list matching the documented syntax (assume the documented syntax is still valid), and add a table test covering these cases? Also while you're there, extractSecret passes the untrimmed value to read.parse even though the filter checks value.trim(), so trimming in one place would keep the two consistent.

@tinaxcodes Just edited the regex to include the cases you mentioned, and added tests with the examples you mentioned! Let me know if there's anything wrong, happy to fix!