Replies: 2 comments 1 reply
-
the connection problem itself would be fixed by the correct label selector here a small example from my side and and a quick and dirty proof: .woodpecker.yaml:
part of the woodpecker wp-1hearh2xfzy85kdyaa0p5zgy0-0-step-0 while the normal creation is:
changed service from:
which results into no attached endpoint to:
which attaches the service to the pipelinelog:
|
Beta Was this translation helpful? Give feedback.
-
You're right. Thank you for pointing me to HostAliases. May close this and fix selector then (#2724). |
Beta Was this translation helpful? Give feedback.
-
From Matrix:
#2656 (comment)
Apart from #2709, it works technically speaking. But is it useful? I think no.
There is no
database
service . There iswp-01he8bebctabr3kgk0qj36d2me-0-services-0
service for example. So, we have to connect to it:It should work:
This name is generated. So, we cannot know it when writing pipeline. Also, AFAIK there is no way to know it inside step.
Solutions I see now:
step.alias
(database
in the example). Service name have to be unique. Otherwise we can't run pipelines simultaneously with the same service name (in the same Kube namespace).WP_01HE8BEBCTABR3KGK0QJ36D2ME_0_SERVICES_0_SERVICE_HOST=10.43.181.50
for example). We can supply some map/dict in our env var:WOODPECKER_SERVICES="database=wp-01he8bebctabr3kgk0qj36d2me-0-services-0,cache=..."
. Or use variable for each service:WOODPECKER_SERVICE_DATABASE=wp-01he8bebctabr3kgk0qj36d2me-0-services-0
,WOODPECKER\_SERVICE_CACHE=...
.Then use it like
mysql -uroot -h$WOODPECKER_SERVICE_DATABASE test -pexample
.Beta Was this translation helpful? Give feedback.
All reactions