Use the job_id to set an environment variable

[eine]

I'm trying to use the job_id to set an environment variable. For example:

  fedora:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: ./run.sh -c $DIST
      env:
        DIST: ${{ job.id }}

However, it is not working. Overall, I feel that contexts derived from the workflow have very little info, too little to be really useful. This is not the case with event sources.

[bryanmacfarlane]

@thboop - can you take a look? Doesn't look like a toolkit issue but perhaps you can answer quickly.

[thboop]

Hey @1138-4eb thanks for the feedback!

This page lists the values available in the context, the job context currently does not contain an Id field.

Overall, I feel that contexts derived from the workflow have very little info, too little to be really useful.

Are there any other fields on any of the contexts that would enable you to build better workflows? I'll make sure to capture those in our feedback ticket as well!

As a side note, you may also want to consider starting a discussion on our community page for this item.

[eine]

Hey @1138-4eb thanks for the feedback!

Thank you for stepping by, and my apologies for taking long to reply...

This page lists the values available in the context, the job context currently does not contain an Id field.

You are correct. This issue is a feature request. The syntax above is just an example among the multiple tests I did before opening this issue. I wrote it because I think it is an 'intuitive' syntax.

Overall, I feel that contexts derived from the workflow have very little info, too little to be really useful.

Are there any other fields on any of the contexts that would enable you to build better workflows? I'll make sure to capture those in our feedback ticket as well!

Let's take the following example (https://github.com/1138-4EB/actions/commit/de2fddd87001ea5fa7227c03320d89834598fbe8/checks):

name: 'push'
on: [pull_request, push]
jobs:
  run:
    strategy:
      fail-fast: false
      max-parallel: 2
      matrix:
        arch: [ amd64, arm, aarch64 ]
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
        STRATEGY_CONTEXT: ${{ toJson(strategy) }}
        MATRIX_CONTEXT: ${{ toJson(matrix) }}
        JOB_CONTEXT: ${{ toJson(job) }}
        RUNNER_CONTEXT: ${{ toJson(runner) }}
        STEPS_CONTEXT: ${{ toJson(steps) }}
      run: |
          printf "%s\n" \
          "GITHUB_CONTEXT: $GITHUB_CONTEXT" \
          "STRATEGY_CONTEXT: $STRATEGY_CONTEXT" \
          "MATRIX_CONTEXT: $MATRIX_CONTEXT" \
          "JOB_CONTEXT: $JOB_CONTEXT" \
          "RUNNER_CONTEXT: $RUNNER_CONTEXT" \
          "STEPS_CONTEXT: $STEPS_CONTEXT"
    - run: yarn

 STRATEGY_CONTEXT: {
  "fail-fast": false,
  "job-index": 0,
  "job-total": 3,
  "max-parallel": 2
}
MATRIX_CONTEXT: {
  "arch": "amd64"
}
JOB_CONTEXT: {
  "status": "Success"
}
RUNNER_CONTEXT: {
  "os": "Linux",
  "tool_cache": "/opt/hostedtoolcache",
  "temp": "/home/runner/work/_temp",
  "workspace": "/home/runner/work/actions"
}
STEPS_CONTEXT: {}

Thoughts:

• JOB_CONTEXT does not contain the name/id of the job, as defined in the YAML. In the example: run. This is the motivation of this issue.
• GITHUB_CONTEXT is ~200 lines long. Does it make sense to have such a large object and then provide 5 different objects for no more than 15 lines/fields of info? I think it would be sensible to have a single ACTION_CONTEXT with fields strategy, matrix, job, runner and steps.
• I'd expect MATRIX_CONTEXT to contain all the options defined in the matrix AND those that apply to the job/step.
  • By the same token, either MATRIX_CONTEXT or STRATEGY_CONTEXT should contain a list of all the jobs generated as a combination of matrix fields. Currently only the number, job-total, is provided.
• runs-on is not available in any context. It would be handy to identify which of the available environments is being used.
• STEPS_CONTEXT does not contain any actual info:
  • name, shell, run, env... fields.
  • uses, with... fields.
  • if fields (probably with resolved variable).
  • status fields.
• Neither JOB_CONTEXT nor STEPS_CONTEXT contain any info about the number of steps (e.g. steps-total).
• When using actions/checkout@v1, the path where the repo is cloned is only specified with GITHUB_CONTEXT. It is {{ runner.workspace }} + {{ github.event.repository.name }} or {{ github.workspace }}.

[bryanmacfarlane]

The contexts are rational is mostly around being able to reference them in yaml conditions and data values. They are separate because things like the github context and event payload are opaque (new events, data can be added) and about the event which are independent to the actions job and step context which is more about the graph execution.

It's covered here:
https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions

I'm going to close as this is not so much about the toolkit. It's more about the language design and the contexts.

As pointed about above, feel free to open service discussions on the github community site: https://git.luolix.topmunity

FYI @chrispat

[eine]

I'm going to close as this is not so much about the toolkit. It's more about the language design and the contexts.

Precisely, my previous message was a direct reply to @thboop asking for specific feedback. I'm already redirecting my questions to the community site.

[bryanmacfarlane]

Awesome. thanks @1138-4eb

Note that I also cc'd @chrispat above from lang product so he has context.

[andrewhibbert]

This still doesn't seem to work. It makes it difficult to write re-usable code when there aren't these kind of variables available