artifacts: use git commit sha in name

[Habbie]

I removed the PR template because this is not a package update. This PR adds the commit hash to the artifact filenames (the packages and logs collections), so that downloads of those artifacts can be tracked back to the builds that generated them.

If you like this, here's an additional proposal: I add a small metadata file to each artifact collection, so that, once unpacked, a user can also see what branch, PR number, etc. generated this artifact.

Thoughts?

[aparcar]

Sounds good to me, thanks!

[aparcar]

Thinking about it again the Pull Request number could be more useful since the sha is nowhere really referenced, is it?

[Habbie]

Yes, it's not the most useful - it is in fact the SHA of the merge commit so you need to go to GitHub to figure out what point in master and what point in a PRs evolution come together here.

A PR number, however, is not unique - people might push additional commits after seeing what comes out, rebase because something has been fixed on master, etc.. That's why I picked the merge commit SHA, it is the only thing that is perfectly unique and (somewhat indirectly) holds all the information, it's just not super convenient to use.

(Also, PR numbers might not be unique if people have private forks of openwrt/packages that they do work against.)

I experimented a bit with Python-pkginfo, which grabs PKG-INFO from inside a zip and conveniently exposes the contents - as simple as pkginfo x86_64-97fc916987c134295163039b6b0cf439c52f5fb2-packages.zip.

With that, my current suggestion would be that I PR support for putting that metadata in, and we keep the SHA naming, because it is unique.

Your thoughts are welcome, of course.

[Habbie]

I pondered some more, and I do agree that making the collections easy to find per PR number makes sense. How about x86_64-PR17078-g97fc916-packages.zip? (g for "git hash", which I don't think has to be full size.)