Closed fitz7 closed 5 months ago
Thanks for your contribution @fitz7. Can you please elaborate on which issue you are trying to solve. These changes do not make much sense to me at the moment.
@mvisonneau I'm not 100% sure it's the same case but when trying to use webhooks with matching wildcard, I face this warning (which is actually an error, because the project data is never present in the metrics):
{"level":"info","msg":"project ref not currently exported but its configuration matches a wildcard, triggering a pull of the project","project-name":"mymaingroup/[REDACTED]","ref":"main","ref-kind":"branch","time":"2024-04-17T16:07:17Z"}
{"level":"info","msg":"done looking up for wildcards matching the project ref","project-name":"mymaingroup/[REDACTED]","ref":"main","ref-kind":"branch","time":"2024-04-17T16:07:17Z"}
{"level":"warning","msg":"taskq\"msg\"=\"job failed (dropping)\" \"error\"=\"taskq: got 0 args, wanted 1\" \"task_name\"=\"PullProject\" \"reserved_count\"=1","time":"2024-04-17T16:07:17Z"}
So seems there's some sort of problem when the the project name is passed to the PullProject task. That even if it's present in the call, it's not really passed. And hence that's why @fitz7 is trying to fix it by duplicating the param. Which doesn't seem about right, but most probably fixes that.
My config:
log:
level: info
format: json
server:
listen_address: :9090
webhook:
enabled: true
pull:
projects_from_wildcards:
on_init: false
scheduled: false
environments_from_projects:
on_init: false
scheduled: false
refs_from_projects:
on_init: false
scheduled: false
metrics:
on_init: false
scheduled: false
project_defaults:
pull:
environments:
enabled: true
refs:
branches:
regexp: ".*"
merge_requests:
enabled: true
pipeline:
jobs:
enabled: true
test_reports:
enabled: true
test_cases:
enabled: true
wildcards:
- owner:
name: mymaingroup
kind: group
include_subgroups: true
yeah apologies, I'll update the description shortly. I created it in a bit of a rush at the end of the day
@mvisonneau I updated the description let me know if it is clear now?
@mvisonneau I'm aware It's not been long since the last release, but this fix would really allow to use the exporter for groups with lots of projects. When can we expect a release?
released it as part of v0.5.8 👍
This was not actually passing the arg to the function that was called by the scheduler as the arg
ref.Project.Name
is just the ID of the job.Instead calling
the first
ref.Project.Name
param is the id of the job, the secondref.Project.Name
is the name of the project to pull that gets passed toTaskHandlerPullProject
Finally I've added the actual pull config from the wildcard so that it gets populated from the config file as without this it uses the default config created by https://github.com/mvisonneau/gitlab-ci-pipelines-exporter/blob/main/pkg/schemas/projects.go#L29 which does not use anything from the actual configuration file