Access to the job name?

[Ignigena]

I am trying to get access to the user-configured job name so that my custom action can annotate it's own check run.

From documentation and sample code that I've been able to wrangle together I would expect context.action to have this value. However, it appears this is only ever the same value: [org-name]actions no matter the user-configured job

Not sure if this is the best place to ask, but is this the expected return behaviour of context.action? Is there any way to get the job name or check run ID within my action so that I can provide annotations?

I've been attempting to use the listForRef on octokit.checks but without a check_name I can't reliably assure that my annotation is happening on the correct job, especially if the user has multiple parallel ones configured:

octokit.checks.listForRef({
    check_name: action // This is always "[org-name]actions"
    owner,
    repo,
    ref: sha,
    status: 'in_progress'
})

[xt0rted]

Was just about to ask the same thing. In a v1 workflow using GITHUB_ACTION for the check name worked as expected, but in a v2 workflow my checks are being called xt0rtedeslint-action and xt0rtedstylelint-action which results in extra steps showing in the workflow that never load.

An example of a v2 workflow using these actions can be seen here and a v1 workflow using them can be seen here.

[thboop]

Related to #133, #56
Hey @Ignigena, thanks for the feedback!

We are looking into updating the docs and functionality around creating annotations to make this a smoother experience across the board. The end to end functionality around using problem matchers to create annotations is currently being worked on, and we would recommend you use that approach.

That being said, I'll take the feedback around making the job name available back to the team, I could see that being a part of the job context if that feature ends up being added

[Ignigena]

and we would recommend you use that approach

Just to clarify "that approach" from what I'm reading on the linked issues:

• Right now there's no reliable way to trigger annotations in the same job context as the current run. This used to be possible in V1 of Actions using the job name, and y'all will discuss some method of bringing this back for V2

• The recommended approach in the meantime is to create a new job and perform annotations on this job (since you'll have the Job ID in this case) The downside to this approach is that it doubles up your job list; so if we have an "ESLint" task in our workflow the annotations won't come through on that job but as a completely separate job on the build.

While the workaround does work (we've used this in a crunch) it definitely creates a confusing experience for everyone on the team. We already have our workflow broken up into several jobs and having these duplicated in our status checks makes it hard to know where to look when a build fails.

As we increase complexity in our jobs, being able to have access to the job name or job ID in the job context will become increasingly critical. I appreciate you taking this feedback back to the team -- the types of automations we're able to create going forward would only be possible thanks to the integrated capabilities we get out of Actions and this would be a big barrier into being able to effectively use it to it's fullest extent.

[thboop]

The recommended approach in the meantime is to create a new job and perform annotations on this job (since you'll have the Job ID in this case) The downside to this approach is that it doubles up your job list; so if we have an "ESLint" task in our workflow the annotations won't come through on that job but as a completely separate job on the build.

This is more of a workaround for the current feature set.

This used to be possible in V1 of Actions using the job name, and y'all will discuss some method of bringing this back for V2

We will look into making the job name available in the toolkit.

However, we are developing flows to add annotations in the toolkit as a core command, rather then using the octokit library. The main example of this is via the problem-matcher command, but this could extend this to other commands or new commands. Once this functionality is available, we will update the docs in the toolkit on issue #56 with how an action can create annotations.

Ideally, once these core command(s) are ready and we have the the back-end is processing these into annotations, our recommendation to create annotations will be using these commands.

Please let me know if you have any more questions! Otherwise, I'll go ahead and close out this issue, and we can keep #56 as the primary issue.

[Ignigena]

Ahh yes thank you for the clarification. If this is a core command to add notations it would solve all of these concerns. I'll follow along on the other issue and try it out as soon as you have something ready to start testing.

[thebeline]

@thboop

we are developing flows to add annotations in the toolkit as a core command, rather then using the octokit library.

This was some time ago, and there still don't seem to be any documented ways to use an API to add annotations. Has there been any progress on this?

Note: There ARE documented ways on how to add Annotations to a Check-Run/Job, HOWEVER, there are no documented ways to get the current Job/Check-Run ID from within a Job (this is different from the github.runId and runNumber that have been suggested before).

I am surprised this is still missing. ProblemMatchers are fine and all, but they do not allow column or line ranges. Additionally, if we had access to the actual Job ID, we could go so far as to make Review Comments and much more. Why this isn't something we have ready access to is just confusing...

[bitdivine]

Current method for getting the job name, in case anyone else lands here:

      - name: Get job name
        run: |
          echo "Job name is $GITHUB_JOB"
          echo "How about ${{ github.jobs[github.job].name }}"

[couling]

👆 That doesn't work for matrix builds