It is currently May 26th, 2020, 8:24 pm

distribute skins via github and release via github actions

Report bugs with the Rainmeter application and suggest features.
User avatar
2bndy5
Posts: 13
Joined: February 25th, 2015, 2:38 am

distribute skins via github and release via github actions

Post by 2bndy5 »

:welcome: Has the idea of using github to distribute skins been standardized? Since DeviantArt.com doesn't seem to support Markdown or reStructuredText in the descriptions, I thought maybe I can use a github repo's readme file. Then it would be easier to include some documentation on certain features of a skin that aren't too obvious or have conditional quirks. I suppose we could still use DeviantArt to host the preview image (although that can be done through github also). Additionally, it would be easier to encourage group collaboration or bug fixes on a certain skin. 8-)

Now I'm wondering how we could use github actions to package a skin for release using the same method I use to create a .rmskin file through rainmeter. Of course I'm assuming one skin per repo, but the possibility to split a suit of skins located in one repo may also be desirable. I did find out that we can specify "windows-latest" on the github-hosted runners. Now what would I have to do to make github actions package a skin into a .rmskin file? Would it be as easy as creating a zip file and renaming the extension rmskin (in that case - why not use linux env)?
User avatar
Brian
Developer
Posts: 1994
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: distribute skins via github and release via github actions

Post by Brian »

2bndy5 wrote:
May 18th, 2020, 8:32 am
Has the idea of using github to distribute skins been standardized?
I am not sure any standardization is really needed as many skin authors already release their skins on github. I don't think there is any "right" way of storing skins on github....but it would be better to add your packaged rmskin as an asset when publishing a "release". The creation of a "readme" or documentation is totally up to the skin author.

The real problem with github is there is no real "group" feature or easy search (like an image gallery). There is a "search topic", but it requires a search term such as rainmeter or rainmeter-skin...which basic users may not stumble upon. Even then, you literally have to click on each one to "see" what it is all about. Github is really geared for developers, so it may not jive well for the normal basic user of Rainmeter.

I guess we could make a static "gallery" github page where users could submit a link to their github skin project, then we could link to it....but this would be a complicated project to get going, plus a lot of "approval" actions from the team. We currently don't have the time to do this at the moment. If someone wants to submit a proof of concept type of thing to us, I think we would at least discuss it.


2bndy5 wrote:
May 18th, 2020, 8:32 am
Now I'm wondering how we could use github actions to package a skin for release using the same method I use to create a .rmskin file through rainmeter. Of course I'm assuming one skin per repo, but the possibility to split a suit of skins located in one repo may also be desirable. I did find out that we can specify "windows-latest" on the github-hosted runners. Now what would I have to do to make github actions package a skin into a .rmskin file? Would it be as easy as creating a zip file and renaming the extension rmskin (in that case - why not use linux env)?
Yes, this is possible, but it is not as simple as renaming a zip file. We write a custom "footer" to the file in an effort to force authors to use the skin packager in Rainmeter. This is why when you rename your rmskin to zip and add a file, the rmskin is no longer valid. While there is no "automatic" skin packaging in Rainmeter proper, I did create a "proof of concept" automatic rmskin packager using github actions that would zip up the skin files (in rmskin format), then it writes the Rainmeter footer, then automatically upload the rmskin to the github release. This made it really easy to push any changes to your skin files, then just create a github release and the github action would do the rest. My version did use "windows-latest" since I mainly used a powershell script to create the rmskin. The only problem with my version, was it was non-validating - meaning it would zip up any files I wanted then create a valid rmskin that Rainmeter would not understand. I am sure a "validating" script can be made.

We are still debating the pros and cons of an "official" Rainmeter automatic skin package for github actions. We made the rmskin format in an effort to provide a bit more security from malware (which was a real problem several years ago [link] [link] [link]) - so we really encourage skin authors to use the built-in skin packager that comes with Rainmeter. We believe that user-interaction is key...but we do understand that sometimes the effort to create a rmskin package can be difficult for larger skins or skin suites. Since Rainmeter is open source, anyone can figure out how to write our custom "footer", so maybe providing a way using github actions might be acceptable. Time will tell.

-Brian
User avatar
2bndy5
Posts: 13
Joined: February 25th, 2015, 2:38 am

Re: distribute skins via github and release via github actions

Post by 2bndy5 »

I guess we could make a static "gallery" github page where users could submit a link to their github skin project...
I'm not too interested in creating a "gallery" for skins (the search term "rainmeter-skin" seems to work well enough), but I am adamant about the github actions idea as using the "create package dialogue" gets rather tedious.
I did create a "proof of concept" automatic rmskin packager using github actions...
Could you give a link to your work if it still exists?
We write a custom "footer" to the file in an effort to force authors to use the skin packager in Rainmeter.
I appreciate the need for authentication when packaging rmskin files. Correct me if I'm wrong, but it looks like rainmeter's dialoguePackage.cpp adds a string, "RMSKIN", after the CRC data. while also creating a RMSKIN.ini at root of the archive.

My idea for a CLI-type program (IDK powershell script) that takes a skin (path-to-root-dir) and spits out a validating rmskin file (in same dir if output destination is not specified by an argument). Use the metadata section from the first ini file in root dir of package (sought alphabetically if the ini file to load after install is not specified by a cmd arg) to fill in "author" and "version" info. Let the skin's root dir name be the package name if not specified by a cmd arg. If the metadata section doesn't exist and is not specified via cmd args, then abort. If metadata is specified by cmd args, then I'd like the program to add/update it appropriately to skin's on-first-install-loaded ini file (of course this wouldn't apply when a layout is specified to load on first install); in this case semantic versioning may need implementation. My go-to language has recently grown to be python, so I'd probably create a python package (installed via pip) that the github runner could install and use for workflows (this might allow the github runner to use Ubuntu env).

Would it be agreeable to save the metadata to a separate metadata.inc file (similar to the RMSKIN.ini file) in skin's root dir for when the skin is actually a suite of skins with no ini file at root dir (could also apply to skins with an ini file at root)? Is the current implementation of having a metadata section per each skin file supposed to preserve original authors metadata when their work is copied into other skin packages?
User avatar
Brian
Developer
Posts: 1994
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: distribute skins via github and release via github actions

Post by Brian »

2bndy5 wrote:
May 24th, 2020, 12:14 am
Could you give a link to your work if it still exists?
I did not save my "test" repo on github, but I do still have a local copy including my workflow file. I haven't had the time to come up with a proper validating script yet. I could re-upload the repo, but I would like to get a validating script working before publishing to github.

The tricky part with rmskin validation is checking the folder structure especially for plugins and layouts. I think it will be hard to check the proper "bitness" of plugins - which might be a deal breaker for this whole thing. Documenting the RMSKIN.ini file and its options should be easy part.

2bndy5 wrote:
May 24th, 2020, 12:14 am
I appreciate the need for authentication when packaging rmskin files. Correct me if I'm wrong, but it looks like rainmeter's dialoguePackage.cpp adds a string, "RMSKIN", after the CRC data. while also creating a RMSKIN.ini at root of the archive.
Right. The "custom footer" Rainmeter appends to the zip file is basically 3 components. The size of the zip (without the footer), a null byte (for future use) and the string "RMSKIN" (null terminated). You can write that custom footer with 7 lines of powershell code (maybe less).

2bndy5 wrote:
May 24th, 2020, 12:14 am
My idea for a CLI-type program (IDK powershell script) that takes a skin (path-to-root-dir) and spits out a validating rmskin file (in same dir if output destination is not specified by an argument). Use the metadata section from the first ini file in root dir of package (sought alphabetically if the ini file to load after install is not specified by a cmd arg) to fill in "author" and "version" info. Let the skin's root dir name be the package name if not specified by a cmd arg. If the metadata section doesn't exist and is not specified via cmd args, then abort. If metadata is specified by cmd args, then I'd like the program to add/update it appropriately to skin's on-first-install-loaded ini file (of course this wouldn't apply when a layout is specified to load on first install); in this case semantic versioning may need implementation.
This was similar to my initial thought process as well for this project except the semver stuff. My test repo was fairly basic. It looked something like this:

Code: Select all

.github\workflows\release.yml
RMSKIN\RMSKIN.ini
RMSKIN\Skins\ ...
RMSKIN\Layouts\ ...
RMSKIN\Plugins\ ...
README
As you can see, the "RMSKIN" folder is in the same format structure as a unzipped rmskin. My "release.yml" workflow ran when creating a github release. So when I would create a release, the action would checkout the code, create the zip archive, apply the footer, change the .zip extension to a .rmskin, then automatically upload the "asset" to the release that was already created. It's like 54 lines (that is with logging).

In my version, it used the name of the repo as the name of the rmskin. The "tag" created during the release was used as the version of the rmskin. After I got it all done, I realized all that information was already in the RMSKIN.ini file - so I am not sure it makes much sense to make another "config" style file. You could even have the github action commit the "tag" version to the RMSKIN.ini file afterward so you didn't have to update that file before the release.

2bndy5 wrote:
May 24th, 2020, 12:14 am
My go-to language has recently grown to be python, so I'd probably create a python package (installed via pip) that the github runner could install and use for workflows (this might allow the github runner to use Ubuntu env).
The beauty of github actions is you can switch environments and use different types of scripts. While, I don't think python or Ubuntu is necessary in this case, you may be able to use them if you are more comfortable with them. I tried using a Ubuntu runner initially, but I ran into trouble uploading the rmskin to the release. It was interpreting the rmskin as a zip and erasing the custom footer. I never figured out if it was the Ubuntu runner I was using, or my test of github artifacts. I gave up on both of those.

2bndy5 wrote:
May 24th, 2020, 12:14 am
Would it be agreeable to save the metadata to a separate metadata.inc file (similar to the RMSKIN.ini file) in skin's root dir for when the skin is actually a suite of skins with no ini file at root dir (could also apply to skins with an ini file at root)? Is the current implementation of having a metadata section per each skin file supposed to preserve original authors metadata when their work is copied into other skin packages?
I really don't think this is necessary at all. Just create a proper RMSKIN.ini file, and all the metadata needed should be there. Your workflow can just "read" the data from the RMSKIN.ini file itself. I see no reason to create another "config" file that creates the RMSKIN.ini file or the use of any arguments.

...but, documenting the contents of a proper RMSKIN.ini will certainly be needed. There is only a few options, so it shouldn't be too difficult.

-Brian