upload nightly to deken, manual upload setting for release#118
upload nightly to deken, manual upload setting for release#118jamesb93 merged 1 commit intoflucoma:mainfrom
Conversation
|
just a sidenote (and I didn't see this PR, so I started #119 which is in the same vein): as the admin of the deken server, i see that people are searching for |
there should be quite a few of my "fluidcorpusmanipulation" (or truncated with wildcard) searches in the logs from the times i tested the deken upload. :) i agree with #119 by the way. when first installing it, i was confused about the directory name since i also expected so for "SEO" reasons (and based on your deken insights), naming it i don't have a strong opinion right now - but i'll gladly adapt this PR if needed. EDIT: if there's a decision to add breaking changes, the name of the library binary might also be questioned (i would have expected |
me neither :-) my entire interaction with this team was merely triggered by a recent glance at the deken log files to look for patterns in searches that don't return any results (in the very late wake of this thread), and |
I would be overreaching to ask, but I will anyway: it might also make sense to consider implementing fuzzy search on the server side. Flucoma and FluidCorpusManipulation could then get people where they need to go relatively equally. I've had good success with: https://github.com/leeoniya/uFuzzy |
we already have a feature request https://git.iem.at/zmoelnig/deken-server/-/issues/28 that goes into that direction. however, my idea of "fuzzy search" was always about guessing the users' intent rather than fixing the maintainer's intent.
ah well.
personally I think it is overkill. but then: PRs are welcome https://git.iem.at/zmoelnig/deken-server/ |
|
ok we've merged and it doesn't upload... I'll try to see why |
this removes the deken upload logic for
releaseruns and just expects the checkbox in the manually dispatched run (seems more elegant and logical anyway):besides that (and more importantly),
nightlybuilds are also uploaded to deken - as suggested in #111 (comment). the version is derived the same way as for releases, but an additional-nightlysuffix is added. the result looks like this (these were my test runs and i removed the packages again):this works pretty well; the only issue that i see is that users will probably install the nightly version by default - the deken app has preference toggles to only display the latest version and only for the system architecture. with these set, the result looks like this (but it's obviously exactly the same for Gem snapshots):
to properly run, this requires flucoma/actions#8 and a
v6tag on the actions side.