Add deken upload

[ben-wes]

this PR was motivated by some users asking for a simple FluCoMa installation via deken.

• closes push package to decken #69

it adds a new deken-upload workflow which is triggered after a successful release.

a FluidCorpusManipulation deken package is created and its name and content is printed in the workflow summary and uploaded as an artifact (see https://github.com/ben-wes/flucoma-pd/actions/runs/18846787301 as an example).

the actual upload to deken is only triggered if the release was made on the production branch. the upload requires DEKEN_USERNAME and DEKEN_PASSWORD secrets.

README.deken.pd is a new patch that automatically opens after the installation. it provides direct access to the preferences for adding path and library - and also a button for adding the flucoma folder to Pd's search path. unfortunately, this doesn't seem possible for the fluid_libmanipulation library, so it needs to be added by the user.

it also links to the object overview and displays the reference launcher:

feedback welcome - the workflow might not be the most elegant. and obviously, the patch is also mainly a suggestion (the use of the add-to-path message is slightly hacky, but should work well afaict).

... thank you for your work and for sharing FluCoMa with everyone!

[jamesb93]

This PR looks good, but I think we can just fold it into the actions repository and call it in release.yaml. Then it just becomes a step of that process rather than a separate action that can fail (ideally they would fail or succeed together).

https://github.com/flucoma/actions

So what I imagine is a new folder deken containing an action.yaml that would instead get consumed in the release.yaml workflow that already exists.

What do you think @ben-wes?

[tremblap]

... and I am still waiting for the puredata.org account creation for us to be able to upload.

[ben-wes]

What do you think @ben-wes?

thanks for your feedback, @jamesb93 ! ... sounds good and cleaner to me for sure. how should we proceed? should i try to add that other PR for the actions repo and update this one here accordingly?

[jamesb93]

What do you think @ben-wes?

thanks for your feedback, @jamesb93 ! ... sounds good and cleaner to me for sure. how should we proceed? should i try to add that other PR for the actions repo and update this one here accordingly?

Exactly. Have a go and if you get stuck at any point I'm more than happy to help. Just @ me.

Where it might get difficult is testing it works as GitHub actions is a total pita for this. What I'd suggest is making it so that the release branch also captures branches called deken-* so we can spin off branches to push and test.

[ben-wes]

@jamesb93 this is now updated and should ideally work combined with flucoma/actions#7 and a v6 tag on the actions side.

i'm not sure it's acceptable that i now updated the release.yml to upload an additional archive for macos to simplify the extraction for the deken packaging? i probably missed some detail there in the new version - but i just couldn't get the dmg extraction to properly work again there.

for testing, we should now also get a deken release from a branch that is named deken-*. and the content of the deken package should also be logged for any other branch.

EDIT: some additional information for the deken tests ...

• from my experience, the uploads will be visible on https://puredata.info/Members/<username>/software/ (when logged in) a bit before they appear on https://deken.puredata.info/
• when clicking in the external's folder (https://puredata.info/Members/<username>/software/FluidCorpusManipulation/), there is an action -> delete option on the upper right side of the frame, which can be used to remove the deken upload again.

[tremblap]

also I have received the login for flucoma - i can put the deets in a secret if @jamesb93 tells me how 😆

[ben-wes]

squashed the changes to make the PR a bit cleaner.