Actions: Identifying keywords like `with`, `shell`

[elizabethtl]

Description of the issue

Hi, is there a way to identify fields such as

• with and the inputs passed into with, example
• other fields such as
  • shell, example
  • continue-on-error, example

I digged into the CodeQL source and did not find classes for these more specific keywords. It would be super helpful to have them.

Any documentation on how I could add classes in myself would also be super helpful, thanks!

[smowton]

with: try

from Uses u, Expression e, string argName
where e = u.getArgumentExpr(argName)
select u, e, argName

shell:

from Run r, string shell
where shell = r.getShell()
select r, shell

(note that per

codeql/actions/ql/lib/codeql/actions/ast/internal/Ast.qll

Line 1452 in f5ea929

string getShell() {

this does a bit more than just read out a literal syntactic shell declaration, so if you just want a shell attribute on a single step you might want to follow the pattern for continue-on-error)

continue-on-error: There's no friendly interface for this one, but you can do:

import actions
import codeql.actions.ast.internal.Ast

from StepImpl s
select s, s.getNode().lookup("continue-on-error")

[elizabethtl]

Thanks, that helps a lot!

Related to this, if I want to identify env (example), how would I do that?
I tried the following query but that did not return results, I may be misunderstanding how Env works

from Env env
select env

However, using EnvlImpl finds the environment variables

Any help on understanding differences between Env and EnvImpl or between Step and StepImpl would be helpful, thanks!

[smowton]

I think it's just a mistake -- Env is abstract so should have concrete classes extending it to represent particular cases, but none exist. In fact it is already constrained to EnvImpl, so you can reveal those like:

import actions

class EnvConcrete extends Env { EnvConcrete() { any() } }

from EnvConcrete e
select e

In the JavaScript library there are JobEnv, StepEnv and WorkflowEnv which are particular cases of Env; I expect this mistake crept in in converting the library.

Step and StepImpl on the other hand work as intended: StepImpl just exposes more of the underlying mechanism whereas Step hides parts of the representation that are liable to change and not part of the public API. Actual instances should be in one-to-one correspondence.

[smowton]

Proposed simple fix: #19675

[elizabethtl]

Thank you for the explanation and fix!