Download Metrics and Stats on the website

[xynydev]

Here's the relevant code for the webpage you've been sharing https://github.com/Aveek-Saha/GithubStats/blob/master/src/components/Data.vue.

It's pretty old, but apparently the GH api just gives this data out. It would be pretty neat to have the data in the download buttons. I'm not quite sure how to go about that in Mkdocs, though.

[castrojo]

Alright let me scope this out a bit better, we now have release artifacts. I'm thinking two charts, one for initial downloads, and then one that shows usage.

These are the ISOs so it should be a chart measuring downloads over time: https://github.com/ublue-os/main/releases - this can be gotten from the github API: curl -s https://api.github.com/repos/ublue-os/main/releases | egrep 'download_count' | cut '-d:' -f 2 | sed 's/,/+/' | xargs echo | xargs -I N echo N 0 | bc

The 2nd one is image pulls. This is not available via the github API so you gotta scrape, we need a stacked chart of the following images: https://github.com/orgs/ublue-os/packages --- name and then pulls. And then also a sum of all of them under "Total image pulls:" and then add them all up. It might make sense to only do the top 10 otherwise the chart will look like a mess but up to you to decide how to present it, if it's too cluttered you can always just link to the packages page.

[castrojo]

Raw stats are on: https://storage.googleapis.com/ghp-stats/ublue-os/data.json

We just need someone to generate a chart and then integrate it into mkdocs-material.

[castrojo]

And here's an initial cut from Kyle:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.7.0/jquery.min.js" integrity="sha512-3gJwYpMe3QewGELv8k/BX9vcqhryRdzRMxVfq6ngyWXwo03GFEzjsUm8Q7RZcHPHksttq7/GFoxjCVUjkjvPdw==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/4.3.2/chart.umd.js" integrity="sha512-KIq/d78rZMlPa/mMe2W/QkRgg+l0/GAAu4mGBacU0OQyPV/7EPoGQChDb269GigVoPQit5CqbNRFbgTjXHHrQg==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

<script type="text/javascript">
$.getJSON('https://storage.googleapis.com/ghp-stats/ublue-os/data.json', function(jsonData) {
    /* Flatten into a label (ublue project name) and array of fetch counts for all dates */
    const flattenedDataset = Object.values(jsonData).reduce((result, data) => {
      Object.entries(data).forEach(([label, value]) => {
        const existingLabelIndex = result.findIndex((item) => item.label === label);
        if (existingLabelIndex !== -1) {
          result[existingLabelIndex].data.push(value);
        } else {
          result.push({ label, data: [value] });
        }
      });
      return result;
    }, []);

    /* Create chart with Chart.js */
    const uBlueChart = document.getElementById('uBlueChart');
    new Chart(uBlueChart, {
        parsing: false,
        type: 'line',
        data: {
            /* Use cleaned up array keys as labels */
            labels: $.map(jsonData, function(element,index) {
                var date = new Date(index);
                var month = date.getMonth() + 1;
                var day = date.getDate();
                var year = date.getFullYear();

                return `${month}/${day}/${year}`;
            }),
            datasets: flattenedDataset
        },
        options: {
            animation: false,
            tension: 0
        }
    });
});
</script>

<div>
  <canvas id="uBlueChart"></canvas>
</div>

[xynydev]

Looks alright, but including jQuery here is really bad practice. Shouldn't be loading all that extra script just for getJSON when modern the fetch API perfectly adequate and nice to use.

[castrojo]

Oh we can just embed this right? https://ublue-images-demo.netlify.app/stats/

[xynydev]

Oh we can just embed this right? https://ublue-images-demo.netlify.app/stats/

(copying my response from Discord)

Here's a better idea: give the images-website a subdomain (images.universal-blue.org or smth), I'll make the stats page have a button that points to the docs, and it can be just linked from the main site.

There's some other org perms related issues I've talked about previously with the images-website (which I obviously can't fix myself) so I'd be happy to go over if/when you have time to fix them.

Edit: I fixed some issues with the stats page and I now create multiple charts from the same stats. I noticed that https://storage.googleapis.com/ghp-stats/ublue-os/data.json doesn't track beyond, for example, but tracks stuff like startingpoint and config.

[castrojo]

We don't need all images-website just the download charts though?

[xynydev]

We don't need all images-website just the download charts though?

Images-website has the charts and the code for them. Treating it as a separate page is better practice than embedding it via some iframe or something, so if you want to use the work I've already done instead of rewriting it I suggest the approach I've been suggesting the whole time.

Besides, the primary point of the site is not the stats, it's the image picker/creator so I don't see a reason to not put it under the official universal blue domain. If you do, please say them out loud instead of downplaying the site's existance.

It's technically correct that this issue could be solved in a multitude of ways, but I find that I've done the bulk of the work already and you're just seeking reasons not to utilize it.

[castrojo]

I am trying to include the stats, but not the image picker/creator. Putting it under the official domain implies that we recommend and support it, which you are free to do of course as an individual.

[xynydev]

Putting it under the official domain implies that we recommend and support it,...

Putting a link to it in the documentation implies that we recommend and support it. It being a repository under the ublue-os org implies that even more heavily. There are happy users but as far as I've seen nobody has said anything against it. Only this sort of implication of there being something against it but no reasons.

The stats are under a subpath of images-website. If you link to that path from the docs, I don't see how that would imply much more support for the image picker/creator than what is already implied in other parts of the docs.

Putting the site under a subdomain would surely make it more official, and of course make it feel more polished. Fixing the other changes I already mentioned in the original GH discussion would turn the project from a "demo" to a "product". I do not understand why you would not want that.

If you absolutely hate web development, or something, like, that's why I am here. If I disappear in a year and the site breaks, just remove the mentions of it from the main website. It shouldn't be a big deal.

[castrojo]

Speaking only for myself, I do not understand the use case for having this or the target user. https://github.com/osbuild already exists and is upstream to an existing commercial product that will probably do all of this better than we can.

[xynydev]

Speaking only for myself, I do not understand the use case for having this or the target user. https://github.com/osbuild already exists and is upstream to an existing commercial product that will probably do all of this better than we can.

Why isn't ublue built with osbuild then? Bazzite, Bluefin, neither is built with osbuild, actually, they are built like container images with traditional container tools. But I don't want to learn all that opaque cloud stuff, I just want to configure and build my own image like all the cool projects do, but just by editing a simple config file. It's not trying to be better, it's trying to be easier. Not to mention Vanilla's Vib, which has clearly a similar goal and is not apparently not considered useless. If you don't think it's a worthwhile part of the ublue project, that's a separate discussion. With regards to who the target user is; it's literally me, I made startingpoint & all the surrounding tools to make life easier for someone like me. They tackle problems I had at first. I think it's neat, and hanging around #custom-image-support it looks like some other people think it's neat too. The main usecase currently is personal images.

But that's all beside the point. The only reason for images-website to exist is not just to be a glorified startingpoint repo setup tool. It also was a gallery site for different native container images, which was removed because the main site implemented the same thing separately. I understand if you're hesitant to somehow officially support the site if you feel that the entire usecase for it does not exist, but in that case, please do not "embed" the stats from images-website either. You are free to implement them separately if you wish, and I can help you not use JQuery.

It'd probably be better, if we wish to discuss this tangential issue further, to not do it inside this unrelated issue, but a separate Github discussion or something. With regards to the statistics, I am still unchanged in my opinion that the easiest course of action for you would be to elevate images-website to a more official status and just link to the stats page their.

[castrojo]

Why isn't ublue built with osbuild then? Bazzite, Bluefin, neither is built with osbuild, actually, they are built like container images with traditional container tools.

Hopefully we can throw away a bunch of code someday, which is why I don't think it's investing time in duplicating work when we have lots of other things that we need that are more important, like metrics on the website. 😄

But I don't want to learn all that opaque cloud stuff, I just want to configure and build my own image like all the cool projects do

Right, so you can do that today without learning how any of the "opaque cloud stuff". Just don't be surprised when the people that do want to learn the cloud stuff have more important things on their plate.

[xynydev]

Right, so you can do that today without learning how any of the "opaque cloud stuff". Just don't be surprised when the people that do want to learn the cloud stuff have more important things on their plate.

Yeah, right, I'm not. That's why I am the one learning the some of the "opaque cloud stuff" and building stuff with it, under the name of the ublue project. Y'all don't have to be burdened by it. But since it is happening under this organization, I thought you'd be open to accommodate for it's existance. And, as I've said, I perceived it to be the easiest option for you to put up links to the charts that I already coded and call them official, instead of having to learn all the opaque webdev stuff to code them yourself. But it is up to you of course, I'm just the underdog here.

[noelmiller]

Reviewing this since it hasn't been touched in a while. Curious if this should move back to Todo until we establish who will own this issue?

I think metrics would be valuable to provide on the website. Is it just a matter of refactoring @KyleGospo initial proposal to align better with best practices?

[castrojo]

@jeefy has volunteered to do this, I'll self assign and we'll bust it out.

[castrojo]

https://universal-blue.org/metrics/