Hide this file and prevent it from being downloaded

[TerryCavanagh]

Heya, very new to butler so apologies if this issue is just me misunderstanding something.

I put off using butler for a long time because I'm always afraid that automated tools will set stuff live before I'm ready. I figured it was just safer to use the website than risk it.

Anyway, my number 1 feature request for butler is this: a flag on butler push commands that defaults new uploads as "Hide this file and prevent it from being downloaded" on the itch.io site. Something like

butler push builds/ user/game:channel --hidden=true

or whatever!

Or: if butler actually does behave this way already, and you don't need to worry about builds going live without authorisation (I'm still unclear about how this works), then say so prominently in the first or second pages of the documentation, preferably in a 90's geocities style animated gif or marquee element text. (It was my biggest question about the whole process, seriously.)

[fasterthanlime]

So, currently, with butler, builds go live as soon as they are processed, so you should only push them when you're ready!

Having "hidden" or "staged" builds is not technically impossible to implement, but it's a design challenge. Each build depends on the build before it, so, let's say there is a way to push a "hidden" build:

• Your upload has a build chain that ends in "v0.15.1"
• You push "v0.15.2" as hidden
• What happens when you push "v0.15.3" without setting "v0.15.2" live? Does it set v0.15.2 live by itself? Does it throw it away?
• Also, how do you set things live? Is it another butler command? Is it a website control? Both?

Also, what's the upside to having hidden builds hang out in the first place? The only upside I can see is that if you push mac/windows/linux builds, they'll all go live the exact same second, instead of a few seconds apart. But you wouldn't really be able to install them to check anything anyway.

That said, beta-testing is important, so, here's one thing people do:

• Have a separate project for the "stable" game and the "beta" game
• Push builds to the "beta" game first, have the developers/testers test it
• If things go well, push the same thing to "stable", knowing that it'll work!

(Nowhere Prophet does this, for example). Of course, that means you need to upload the changes twice, hopefully that shouldn't be an issue with the size of Dicey Dungeons, but we have a pending issue for copying builds from one project/channel to another project/channel, see #34.

I know Steam has separate steps for uploading builds and setting them live - Steam also doesn't do patch optimization the way we do, and I'd rather work out the best solution to the problem you're trying to solve rather than blindly copy what they're doing, so I need to know what you're trying to solve exactly!

[benjymous]

Another use case is having a CI that pushes out regular "unstable" builds - I'd like a human testing process before a build is pushed into the live game

So yes, having a separate project for the CI builds would be fine, all I really want is a nice shiny button somewhere that lets me say "transfer build to other project" (which, I guess would be the equivalent of downloading from "beta" then reuploading to "stable" via butler, just done automatically in the background

[fasterthanlime]

What if:

• Uploads could have "branches", each with their own access level
  • Assume everything pushed until now has been pushed to the "default" branch of uploads
• When pushing, you can optionally specify which branch you're pushing to
  • If you don't, it goes to default
• All branches can be installed, switched between, etc., there's no build "in limbo", they're all associated to a variant of an upload
• From the itch.io dashboard, you could copy a variant to another

---

So, @TerryCavanagh would push builds like so:

butler push builds/ user/game:channel --branch staging

And then copy builds from "staging" to "default" using the web UI whenever he's ready. In that scenario, "staging" is a private branch, not shown to anyone.

---

@benjymous's use case would have CI push builds to

butler push builds/ user/game:channel --branch beta

..and then copy builds from "beta" to "default" using the web UI whenever a human says it's ready. In that scenario, "beta" is a restricted branch, listed but needing a password to switch to?

[benjymous]

Yup, that sounds perfect to me. As you say, there's never any issue about "skipping" builds, as the branches would always just have a live build at the top

[dos1]

👍 from me too!

and then copy builds from "beta" to "default" using the web UI whenever a human says it's ready

Much lower priority, but consider also providing some API (or even butler command) aside of the web UI. External tools (like GitLab) could be then used to manage deployment across various services :)