dynamically determine .drone.yml Grafana versions

[mdb]

This seeks to address issue #411 by dynamically templating the .drone/drone.yml file with the targeted Grafana versions, as provided by the GitHub releases API.

It's currently in a draft state towards the goal of soliciting some early feedback and conversation.

Note that...

• this currently assumes installation of the gh CLI ~, jq, uniq, and sort~, but perhaps should instead invoke a docker run such that docker is the only required dependency
• this currently populates the list of targeted Grafana versions with all those versions returned by the repos/grafana/grafana/releases?per_page=100 endpoint. Rather than fetch the last 100 releases, should we paginate through and collect all releases?
• this currently invokes a shell script from make drone, though there are likely more make-idiomatic ways of accomplishing this without a shell script. Would those be preferable?

[mdb]

@julienduchesne - I'm curious to get your early feedback on this draft PR. I can imagine a different directions to take this, but it's probably worth hearing more about your original vision before I over-invest in a misinterpretation.

[julienduchesne]

@julienduchesne - I'm curious to get your early feedback on this draft PR. I can imagine a different directions to take this, but it's probably worth hearing more about your original vision before I over-invest in a misinterpretation.

That issue was still a bit nebulous to me. I put it down as an idea but didn't put much thought into it.

It's a bit harder than what you're doing:

1. The idea was to have PRs to auto-update in the same sense that dependabot does but that's not really possible because the Drone pipeline signature needs to be generated by a human when the pipelines are modified
2. The versions that we select is essentially: The last patch of every major since 7 (we want the provider to stay retrocompatible as much as possible). The last patch of the last x (5?) minor versions (ex: 9.0, 8.5, 8.4, 8.3, 8.2). We can't select too many versions because running too many tests at the same time is problematic in many ways

Now, I think 1 is just impossible, so I think your solution is as good as we're gonna get, so if you get the versions right, I'd be inclined to merge this and close the issue 😄

[mdb]

so I think your solution is as good as we're gonna get, so if you get the versions right, I'd be inclined to merge this and close the issue

@julienduchesne Thanks for the feedback! I believe I've cooked up a script that implements the logic you describe. Currently, it's a bash script that assumes the installation of gh and jq, though this could be containerized if folks would prefer it only assume the installation of docker (itself already assumed to be installed elsewhere in the GNUMakefile).

[mdb]

The idea was to have PRs to auto-update in the same sense that dependabot does but that's not really possible because the Drone pipeline signature needs to be generated by a human when the pipelines are modified

@julienduchesne Thanks for clarifying! I've removed the actual updates to .drone/drone.yml from this PR, such that this PR merely adds a make drone utility for authorized humans to update the .drone/drone.yml in an automated fashion. Is that a reasonably helpful baby step for now, or do you regard that as unnecessary overhead and complexity? (If the latter, perhaps both issue #411 and this PR should both be closed/abandoned?)

[julienduchesne]

The idea was to have PRs to auto-update in the same sense that dependabot does but that's not really possible because the Drone pipeline signature needs to be generated by a human when the pipelines are modified

@julienduchesne Thanks for clarifying! I've removed the actual updates to .drone/drone.yml from this PR, such that this PR merely adds a make drone utility for authorized humans to update the .drone/drone.yml in an automated fashion. Is that a reasonably helpful baby step for now, or do you regard that as unnecessary overhead and complexity? (If the latter, perhaps both issue #411 and this PR should both be closed/abandoned?)

Yeah, I'm sorry that lead you to invest so much time in this. I can't really bring myself to merge this, the productivity gain is just not enough to counter the additional complexity, IMO.

I opened this issue pretty quick and hadn't investigated the details surrounding the task. Considering the limitations that Drone pipelines have to be generated by a human (for security reasons), and that we want things to be relatively static so that new failures aren't introduced randomly, I don't think we should pursue this any further and we should keep updating manually. I'll close the issue.

Really great work though!