How to expose node name in custom (self-hosted) runners?

[kratsg]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

ARC (Actions Runner Controller)

Discussion Details

We're using the GitHub Actions Runner Controller Helm configuration as documented. At first thought it might be a matter of having scripts run before or after a job but it's not clear if this is the best approach.

To first order, we could expose pod information via environment variables such as

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-fieldref
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never

and would have thought it would be nice to view this information as part of the "Set up job" portion of the action workflow. Is this the correct way, or is there a more preferred way of exposing some of this?

[kratsg]

@Aqib121201 I'm not sure why you haven't been able to link to any documentation. The GitHub ARC follows the PodSpec -- and there's no metadata field described: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec . How do you know what labels you're allow or able to set? Where is the documentation?

[kratsg]

I feel like we're going in circles. To get anything in "Set up job" requires modifying the underlying C# code associated with it. Is there no functionality that will expose the env variable as a printout like in the screenshot I showed above without having to modify the original C# and recompile again?

[kratsg]

No it does not. This reads like AI slop here. Please link documentation or stop using AI to provide answers.

[Milkeles]

Your approach is okay as is, honestly, that's probably how it's usually done, or at least how I would've done it. Regardless, I looked up some more information that may be helpful.

ARC already gives you everything you need since the runner Pod is a normal Kubernetes Pod, so you can inject any Downward-API environment variables you want. The only thing you have to do is add the extra env-vars to the runner container that ARC creates.

There are two supported ways to do that. You can use Helm values globally for every runner by adding the env block with fieldRef values to the runner container spec in your values.yaml file. Alternatively, if you're using the newer RunnerScaleSet or RunnerDeployment CRDs you can put the same env block under the container definition in the template section of the resource.

You don't need an extra init-container or a pre-job script unless you want to compute something that the Downward API can't supply. The variables are already present when GitHub's run.sh starts, so they appear in the "Set up job" step automatically, though the GitHub UI might not show them automatically.

[Milkeles]

You can print them in the set up job with:

• run: echo "$MY_NODE_NAME"
  Since the UI doesn't show them by default

[kratsg]

We don't have access to the set up job step in any of this without touching the C# code.

[Milkeles]

My bad, you're right, you can't touch the Set up job on ARC runners. I'd say your original approach is right as is. Though, if you want the metadata printed visibly for debugging or other purposes, you could add a step at the top of every workflow or have a reusable workflow that runs before the rest for that. Not sure if this helps for your situation but I think you're already doing it right, so can't think of anything else that may be useful. 🙏

[kratsg]

I'm just surprised there's not much ability in configuring or customizing the Set up job so easily, as the GitHub shared runners do this, compared to the code provided by actions/runner.

[queenofcorgis]

Hi @26ryxn ,

We’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.  You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[kratsg]

No solution has been found.