Does anyone know of a way to automate publishing of a Roku channel? I’ve built a toolchain that performs some custom build steps and outputs either a .zip or .pkg file. I often do builds which I upload to a private channel for testing, and I find it cumbersome to login and navigate the website each time. I’d love to add another option to my build script which performs the upload.
I investigated using mechanize, however it doesn’t execute javascript (which much of the site relies on).
“Rek” wrote:
Does anyone know of a way to automate publishing of a Roku channel? I’ve built a toolchain that performs some custom build steps and outputs either a .zip or .pkg file. I often do builds which I upload to a private channel for testing, and I find it cumbersome to login and navigate the website each time. I’d love to add another option to my build script which performs the upload.
I investigated using mechanize, however it doesn’t execute javascript (which much of the site relies on).
Has anyone tackled this successfully?
I’m going to take the lack of replies as a resounding “no”.
@Roku*: If there is not currently a logged request for an API which would make this possible, then I request one
I can’t think of a single good reason to do this, and about a million good reasons not to. How often are you publishing updates to channels that you need to automate it, and is it often enough to risk writing a script that could do it accidentally? Sounds very dangerous to me…
“TheEndless” wrote:
I can’t think of a single good reason to do this, and about a million good reasons not to. How often are you publishing updates to channels that you need to automate it, and is it often enough to risk writing a script that could do it accidentally? Sounds very dangerous to me…
I agree that it has the potential to do damage if misused. It wouldn’t be for publishing to production. Only myself and a few coworkers have access to the private channel.
Google has an API in place for play store which allows this already. I believe the iOS app store does too.
Hmmm, publishing an app is like a sharpshooting contest - and you are asking to be allowed to bring in a machine gun!
Next thing you know, some XP enthusiast will figure that is a great opportunity to do continuous deployment and start peppering RokuCo’s backend with buckshot. That is beyond annoying - it is expensive. There is a good chance Co’s file storage does not even delete old packages, keeping them in perpetuity.
Your q. made me thinking and here is an idea: use side-loading for yourself and your colleagues.
With a twist: at start, channel checks and if roAppInfo.IsDev() then POST roAppInfo.GetVersion() to a web service at a shared server - and then continues executing as usual.
That staging server will be the one hosting latest version of your app. When it gets tickled by a Roku, it will check if the submitted version# is older than the one it has - and if so, it will retaliate by POST uploading the new pkg at the client IP (which causes app to re-start). Else it will keep truce.
“destruk” wrote:
Ah, but running your own ‘channel store’ - even for a single channel, is against the developer agreement.
Not a channel store. Have you read the opening recitations of said agreement - or did you have unrelated pet-peeve you thought you’d bring to the thread?
“Channel Store” means a storefront of channel applications that Roku makes available to End Users in a
defined territory, which storefront is provided by the Player as an on-screen menu that permits End Users
in the applicable territory to browse and install said channel applications on their Player.
You can stop at the 3rd word of the definition - “storefront”. No “storefront” => not a “channel store”. There are other reasons, if you continue reading but one is enough.
Maybe you should read the thing Enterr. You don’t have to ‘like’ what is said, but it is in there.
Page 5 of 14 –
Channel Application Restrictions and Requirements; Rights to Code.
“D. Developer may not use the SDK to (i) enable the installation of third party channel applications, or (ii) to create Developer’s own version of a Channel Store.”
By ‘bypassing the channel store’ you are effectively allowing your friends to run code which is neither a public nor private channel - as a sideloaded application - meaning your install is using a ‘developer’s own version’ of a channel store which offers one or more dev packages to install.
Of course how Roku could enforce this to prevent you from loading stuff outside their control isn’t the scope here – what is is you are breaking the agreement by doing so - which doesn’t mean anything to some people.
“destruk” wrote:
Maybe you should read the thing Enterr. You don’t have to ‘like’ what is said, but it is in there.
Page 5 of 14 –
Channel Application Restrictions and Requirements; Rights to Code.
“D. Developer may not use the SDK to (i) enable the installation of third party channel applications, or (ii) to create Developer’s own version of a Channel Store.”
Okay, so now you are changing your “objections”. First you said that was "running your own ‘channel store’ " and i showed you it isn’t - by directing you to the definition of what a “channel store” is.
Now you point you actually meant 5-D, which puts limits on the use of SDK. Worth looking at, since somehow you are having difficulty understanding it. Part (ii) is not applicable to the case, since we established this is not a “channel store” per contractual terms (see above, pray over it, sleep over it etc). Part (i) limits the use of SDK for “installation of third party channel applications” - and indeed you would have a point, were this a 3rd party app - which it isn’t, if i properly understand the situation, with Rek as an agent of his employer, who is the “Developer” for the agreement. Read the preamble, see also this definition:
“Authorized Developers” means Developer and Developer’s employees, third party contractors, and
agents engaged in development of the Channel Application.
The case is even stronger - not only is this not a “3rd party app” but it is not being installed to a third party - Rek’s co-workers are also Authorized Developers. Within the bounds of a “developer” organization, there is no “3rd party” nor is the app a “3rd party app”.
By ‘bypassing the channel store’ you are effectively allowing your friends to run code which is neither a public nor private channel - as a sideloaded application - meaning your install is using a ‘developer’s own version’ of a channel store which offers one or more dev packages to install.
There are so many things wrong with this, i am getting tired just trying to count them
nobody is ‘bypassing the channel store’ (who were you quoting - yourself?)
those are not “friends” - they are employees under the same roof, on the same LAN, which are authorized under the SDK agreement to sideload apps
there is no “channel store” being made (see above for N+1 time)
nothing “offers one or more dev packages to install” - seems you did not even understand what i proposed, which makes me sad
All in all, i am tired explaining to you a fairly straightforward matter. If still in doubt, call Roku Inc’s legal counsel and maybe he will explain it to you. Alternatively, consult an attorney. I trust Rek can draw his own conclusions.
Thanks for all the great info everyone. I think we’ll just stick with the old fashioned upload process for now.
Although I am very tempted to build the staging server you speak of EnTerr – but it doesn’t quite meet our needs. With that solution, the Roku devices and staging server would either need to be on the same local network, or the Roku’s gateway would need to be configured to forward ports required for uploading a package. Otherwise the server would not be able to “push” the update after being tickled
