Possible good first task; needs the current output to be scped from people to doc, the code to be moved to doc and installed in a crontab, and then properly puppetised so it stays around the next time the host gets re-imaged (but that could be a separate, spun-out task).

@Jdforrester-WMF: good first task is for tasks which do not require any special permissions in order to test the contribution or to fix the task. Anyone should be able to reproduce. As scp was mentioned I assume that's not the case but please correct me if I misunderstand!

Where is the source code for this?

In T255701#6261192, @Aklapper wrote:

@Jdforrester-WMF: good first task is for tasks which do not require any special permissions in order to test the contribution or to fix the task. Anyone should be able to reproduce. As scp was mentioned I assume that's not the case but please correct me if I misunderstand!

We're intentionally using the tag for tasks for our new starter. I hope you've not removed it from all those carefully curated tasks? Eurgh.

In T255701#6262992, @Legoktm wrote:

Where is the source code for this?

On people1002:/home/dduvall.

Alternative is to have a regular Jenkins job to generate the reports then publish to doc1001. That has a few benefits:

• keeps doc1001 pristine clear and just hosting static assets
• we can retrigger / tweak the batch however we want via JJB/Jenkins config

We should also get the scripts published in some git repo (maybe integration/config is a good enough fit for that).

(else yeah +1 on the principle of having it documented / shared ;D )

[OT] @Jdforrester-WMF: I hope you (plural; team) will remove the tag from all those tasks, otherwise I will have to do that soon. Thanks :)

You should take that up with the owners of Phabricator. ;-)

In T255701#6264260, @Jdforrester-WMF wrote:

In T255701#6262992, @Legoktm wrote:

Where is the source code for this?

On people1002:/home/dduvall.

I pushed it to gerrit a while back, and there's a patch that needs merging. After that, it should be easy to restore the cron job. Long term, this should be moved to WMCS. I can probably hack on that in the near future.

I somehow never noticed https://gerrit.wikimedia.org/r/c/integration/reporting/+/589083 , I gave it a quick review and just submitted it :]

Would be nice to have it run on one of the production machine, as to where and how I don't really now:

• a Jenkins job on CI, though I would like to eventually remove the timed jobs
• a Jenkins job on https://releases-jenkins.wikimedia.org/ , but it would not be able to publish outside of that
• a cronjob on the primary contint that would potentially published somewhere under https://integration.wikimedia.org/ (I have some work going on to have files publishable under that host) potentially using a ruby docker container.
• or yeah wmcs.

In T248351, @dduvall wrote:

It would be nice to get our Jenkins build records into something more flexible than the current CSVs generated by my random ruby scripts. Let's spend a little bit of time seeing how much work it might be to have biterg.io scrape our Jenkins API endpoint.

They have a scraper.

https://github.com/chaoss/grimoirelab-perceval/blob/master/perceval/backends/core/jenkins.py