mvisonneau / gitlab-ci-pipelines-exporter

Prometheus / OpenMetrics exporter for GitLab CI pipelines insights
Apache License 2.0
1.27k stars 240 forks source link

fix project pull webhook args #828

Closed fitz7 closed 5 months ago

fitz7 commented 5 months ago

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.

c.ScheduleTask(context.TODO(), schemas.TaskTypePullProject, ref.Project.Name)

Instead calling

c.ScheduleTask(context.TODO(), schemas.TaskTypePullProject, ref.Project.Name, ref.Project.Name, w.Pull)

the first ref.Project.Name param is the id of the job, the second ref.Project.Name is the name of the project to pull that gets passed to TaskHandlerPullProject

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

mvisonneau commented 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.

gcuberes commented 5 months ago

@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
fitz7 commented 5 months ago

yeah apologies, I'll update the description shortly. I created it in a bit of a rush at the end of the day

fitz7 commented 5 months ago

@mvisonneau I updated the description let me know if it is clear now?

coveralls commented 5 months ago

Coverage Status

coverage: 65.401% (+0.05%) from 65.356% when pulling d012ee098736a122517570f6bd8859188164693b on fitz7:fix-pull-projects into f3ed82967134937bce69ac063993c4b3c6bfb6d8 on mvisonneau:main.

gcuberes commented 5 months ago

@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?

mvisonneau commented 5 months ago

released it as part of v0.5.8 👍