Add the ability to override default env variables for Kubernetes pipeline steps

[dominic-p]

Clear and concise description of the problem

I'm trying to run a buildah container in my pipeline which requires the HOME variable to be set to /home/build. Currently, the HOME variable seems to be hardcoded to /root here.

Suggested solution

It would be nice if we could use the standard pipeline environment variable config to override the HOME (and other) variables like so:

steps:
  build:
    image: quay.io/buildah/stable:v1.33
    environment:
      - HOME=/home/build

Alternative

I'm not sure if running a command before my main command like export HOME=/home/build will work. I haven't tested it yet. If that works, it would be a nice workaround. But, it would still be good to be able to set the variables directly, in my opinion.

Update: I have confirmed that I can run this at the beginning of my build scripts, and it works. So, we have a good workaround. I still do think it would be nice to be able to specify it in the pipeline config with other env variables.

Additional context

This is part of my ongoing efforts to get buildah running on Woodpecker (#2545). This should be the last piece of the puzzle once the AppArmor PR lands!

Validations

• Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[maltegrosse]

@dominic-p I got buildah up and running (somehow) on k8s.... just have a look here: https://github.com/maltegrosse/woodpecker-buildah (please consider the performance vs. security aspect carefully)

appreciate feedback / improvements :)

[dominic-p]

Thanks for sharing this, @maltegrosse; that looks really cool!

I'm curious how you are passing in registry credentials (see #3582). That's pretty much the last issue I'm having with my cobbled together setup.

By the way, in my particular setup, I have good control over the hosts, so I can make sure that things like fuse are installed and configured correctly to avoid the issues with vfs.

[maltegrosse]

@dominic-p I dont pass any secrets directly from k8s to the ci pipeline - I let users setup their own (gitea) repo credentials.
I think drone is doing it with some plugins, see

• https://docs.drone.io/runner/extensions/kube/
• https://github.com/harness/drone-kubernetes-secrets
• https://github.com/drone/charts/tree/master/charts/drone-kubernetes-secrets

[dominic-p]

Thanks for the confirmation. That's kind of what I figured.

The plugin looks pretty cool, by the way. I'll definitely keep an eye on it. :)

[maltegrosse]

@dominic-p I am facing issues upgrading to woodpecker latest version and my plugin...do you have similiar issues using fuse?
maltegrosse/woodpecker-buildah#1

[dominic-p]

I saw that in the tracker. I'm not currently running the latest WP version in my cluster, so I'm not sure. If I can get some time I'll upgrade and test it out.

That permission denied error looks pretty familiar. I would definitely check the audit logs on your node to see if you can find a corresponding entry.

[ztelliot]

Hello, I have the same problem.
I need to update k8s resources in CI using kubectl, kubectl will determine whether to assume in-cluster authentication based on whether it is in a container environment.
So if I want to access the k8s cluster through the service account, but because HOME is set, it will first look for $HOME/.kube/config and give an error:

error: error loading config file "/root/.kube/config": open /root/.kube/config: permission denied

After unset HOME, kubectl works fine, so is it possible to have an option to control the setting of HOME.