Netrc not passed to clone container

[6543]

the first step of a pipeline is the close step, if not set by pipeline config it will be added by default.

this environment should have access to Netrc variables:

woodpecker/pipeline/frontend/yaml/compiler/option.go

Lines 71 to 87 in 3c5827f

	// WithNetrc configures the compiler with netrc authentication
	// credentials added by default to every container in the pipeline.
	func WithNetrc(username, password, machine string) Option {
	return WithEnviron(
	map[string]string{
	"CI_NETRC_USERNAME": username,
	"CI_NETRC_PASSWORD": password,
	"CI_NETRC_MACHINE": machine,
	// TODO: This is present for backward compatibility and should
	// be removed in a future version.
	"DRONE_NETRC_USERNAME": username,
	"DRONE_NETRC_PASSWORD": password,
	"DRONE_NETRC_MACHINE": machine,
	},
	)
	}

but that's not the case!

block #473 (-> woodpecker-ci/plugin-git#4)

[6543]

workaround: add clone step to your pipeline if not already there and use secrets to pass netrc to git:

 clone:
   git:
     image: woodpeckerci/plugin-git:next
+    secrets: [ ci_netrc_username, ci_netrc_password, ci_netrc_machine ]

[anbraten]

@6543 Why would other steps then clone need netrc creds at all? Isn't that a security risk?

[6543]

it would - I'm aware of that :)

[s00500]

Well... it would if it needs to access different repositories... seems like the
secrets: [ ci_netrc_username, ci_netrc_password, ci_netrc_machine ]
Is not working anymore.... or should it?

Any other way to do this ? (I also see why this is not a nice solution though... seems like in drone these where always available to the containers...)

My current usecase is pulling private go dependencies....

[s00500]

(of course I can always add the data as a secret myself and am happy to go that route if necessary... but would be interesting if there are other ways too...)

[6543]

we could add some special "secret" that injects netrc ... - so it's handled like the normal secrets from permission perspective but the outcome would be a netrc - but that's for a new issue

feel free to open a feature request

[s00500]

we could add some special "secret" that injects netrc ... - so it's handled like the normal secrets from permission perspective but the outcome would be a netrc - but that's for a new issue

feel free to open a feature request

thanks for the update :-)