Replies: 15 comments 12 replies
-
Thanks for the feedback. We should add this, indeed. I'll talk to the team about this in the new year. |
Beta Was this translation helpful? Give feedback.
-
Do you happen to have any news on this topic? |
Beta Was this translation helpful? Give feedback.
-
This would be a very good to have feature. When there is an existing action that uses the GitHub API, you know there is a need for it. Having it in the context, and especially as an environment variable (so that automation can use it too, without having to pass it as a jinja template variable), would be a godsend! 🙏🏻 |
Beta Was this translation helpful? Give feedback.
-
Chiming in from 2023, we really need this. The job I am trying to get the ID for is a matrix job with a stringified JSON object as its value so the name is truncated making the workaround practically useless. |
Beta Was this translation helpful? Give feedback.
-
I'm embarrassed to share this, but I know people are struggling. Here is how I'm getting this to work in every scenario:
if len(provided_job_name) > 100:
possible_job_names.append( provided_job_name[:97] + "..." )
I know this is not pretty but it has been very effective. I really hope Github don't see this as a workaround which delays implementing the fix. If I see that happening I may have to delete this post. I should also add the customary reminder that you shouldn't risk your career or your user's happiness based on a snippet of code you saw someone post on the Internet. |
Beta Was this translation helpful? Give feedback.
-
Our use case for requiring a job Id is as follows: We have software that runs against dozens of different npm packages. Each package run is done in a separate job. If this software fails then we send a Slack message to the team to look at the incompatible npm package. Ideally we would be able to provide a URL in this slack message so that a developer can click it for more information:
|
Beta Was this translation helpful? Give feedback.
-
No it is not: this is the string key of the job, as in jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job |
Beta Was this translation helpful? Give feedback.
-
We could really use the jobid in the github context so on a matrix job so we can provide a html_url to a workflow status dashboard... |
Beta Was this translation helpful? Give feedback.
-
So, it's one of the plenty cases, where GH actions aren't fixing their fundamental issues. Just an example of how we solve it in python https://github.com/ClickHouse/clickhouse/blob/4b7aa30/tests/ci/env_helper.py#L49-L95 The code tries to address either the feature requested in this discussion or in the issue actions/runner#2577 |
Beta Was this translation helpful? Give feedback.
-
We are experimenting with reusable workflows, and it's just the last border before the deepest inconsistency hell. The logs are So, the In Felixoid/actions-experiments@8eaa77a I tried to override the parameter - no luck. update: in tests + concurrency_call (logs_39.zip) I tried to get this variable from at least any place. No luck, neither of the contexts github, runner, env, nor job contains this value. So, the outcome: without kicking around with strange self-invented variables, GH actions not only prevent you from finding an easy way to get the job_id, but any tool you have out of the box will ultimately give a broken solution. Because who needs to know the full Job name, right? |
Beta Was this translation helpful? Give feedback.
-
It's almost 2024 and still no movement on this? It's seems to be impossible to tie a current run to a previous run unless either the |
Beta Was this translation helpful? Give feedback.
-
It's now 2024 and GitHub is still adding job ID in context. We need a way to distinguish one job from another, especially when using matrix. This should not be a difficult thing either, the job ID is already in the URL. |
Beta Was this translation helpful? Give feedback.
-
The impact of this is ultimately an inability to link to logs from a test reporting system. This is critical for our evals setup where debuggable events within the job need to link back to the full job for logs, so I think this could mean we have to switch away from GitHub Actions. |
Beta Was this translation helpful? Give feedback.
-
I said to hell with it and just started using random IDs as suffixes to get around duplicate artifact names. I would have just liked to use the job id for the workflow_call so I can at least trace an artifact back to the job that generated it. Greatly simplified, but this guy runs into trouble when trying to upload artifacts from workflow_call invocations where it's called multiple times in a matrix (or just used multiple times at all) name: Storybook
on:
workflow_dispatch:
workflow_call:
push:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
# ////////////////////////////////////////////////////////////////////////
# Setup tasks
# ////////////////////////////////////////////////////////////////////////
# ////////////////////////////////////////////////////////////////////////
# Run tests
# ////////////////////////////////////////////////////////////////////////
# ////////////////////////////////////////////////////////////////////////
# Upload test artifacts
# ////////////////////////////////////////////////////////////////////////
- name: Generate a unique id
id: gen-id
if: always()
run: |
echo "rand=$(openssl rand -hex 3)" >> "$GITHUB_OUTPUT"
- name: archive storybook junit
uses: actions/upload-artifact@v4
if: always()
with:
name: storybook-junit-${{ github.run_id }}-${{ steps.gen-id.outputs.rand }}
path: junit.xml
retention-days: 7
- name: archive storybook json
uses: actions/upload-artifact@v4
if: always()
with:
name: storybook-json-${{ github.run_id }}-${{ steps.gen-id.outputs.rand }}
path: storybook-run.json
retention-days: 7 |
Beta Was this translation helpful? Give feedback.
-
2 years and a half and this is still a HUGE gap on GitHub API. It makes a lot of possible integrations and useful actions very hard to be implemented. |
Beta Was this translation helpful? Give feedback.
-
Hi,
Right now, it seems that there is no way to identify the job that is being run from inside of the GitHub workflow run.
The
github
context only has the element job, with matches with the string id of the job.But when you try to get the job from the GitHub API, there is no way to match against it. If there is no
name
for this job, you could match them but it is not safe.I think you could add to the
github
orjob
context the id of the job run to be able to query the GitHub API about the current job.I found these community entries regarding this request, but I couldn't find a ticket or discussion regarding this issue:
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions