Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom OS #464

Closed
sdermanffs opened this issue May 22, 2019 · 17 comments
Closed

Custom OS #464

sdermanffs opened this issue May 22, 2019 · 17 comments
Assignees
Labels
feature request New feature request hockeyapp Related to HockeyApp's transition to App Center

Comments

@sdermanffs
Copy link

sdermanffs commented May 22, 2019

Describe the solution you'd like
The ability to support apps that don't fit into the supported OSes (iOS, Android, Windows, macOS). Please add Custom similar to how HockeyApp supports Custom. For example, Hololens.

Additional context
We have a number of apps migrated from HockeyApp. Many of these are not one of iOS, Android, Windows, macOS apps and therefore we use the "Custom" OS setting.

@sdermanffs sdermanffs added the feature request New feature request label May 22, 2019
@patniko patniko added the hockeyapp Related to HockeyApp's transition to App Center label May 23, 2019
@lacostej
Copy link

We will need this as well.

@dipree
Copy link
Member

dipree commented May 31, 2019

Thanks for bringing it up, we have it tracked on our roadmap

Custom apps platform support

@lbrownell-gpsw
Copy link

One of our "apps" is a plugin (for Mac and Win), that is installed via a .pkg on Mac and .exe on Win. It is not an app -- it is a single file of a specific odd type required by the app for which it is a plugin. Right now, I can't upload it to App Center.

Thanks.

@dipree
Copy link
Member

dipree commented Jun 14, 2019

@lbrownell-gpsw on HockeyApp, does it currently reside as a custom app?

@lbrownell-gpsw
Copy link

@derpixeldan Not yet.

This is new, thought I'd try creating our first native App Center app, epic fail!

We do have some custom apps in HockeyApp -- for example, Windows apps that install via an .exe, not an .msi, and some mobile SDKs that are in a .zip file, containing frameworks, documentation and sample apps. We also used to package up build artifacts/logs and save them as custom "apps" as well, but we push all that to Artifactory now.

@Bart-Verdonck
Copy link

Can we expect this feature to be present once HockeyApp is no longer available. (16 November?)
Otherwise we'd have to look for a temporary solution as we also use HockeyApp to host standalone-installers (*.deb, *.dmg and *.msi; each packaged in a *.zip)

@dipree
Copy link
Member

dipree commented Jul 3, 2019

Yes, everything on the roadmap will be available before the shutdown.

@martinarvaiaccedo
Copy link

martinarvaiaccedo commented Sep 25, 2019

Hi! Any update on this? Besides Android, we work with Samsung Tizen and LG WebOS applications. It would be good to either support these or simply support the "Custom Platform". Both Smart TV platforms are javascript applications.

Parsing the version would be fairly easy for both of the platforms. Both provide unzippable archives:

  • Tizen contains a config.xml with the version in it
  • WebOS contains an appinfo.json with the version.

Thank you in advance!

@gautamkrishnar
Copy link

For more info

It's better if you can implement signing of lg and tizen applications in appcenter.

@lbrownell-gpsw
Copy link

Re: my comment above, we have rid ourselves of all our custom apps except the plugins I described above. They are currently in HockeyApp as custom apps.

When I look at them in App Center, it asks me to classify them as one of the supported types.

So, obviously not there, and it's a bit scary that in the October Iteration, "Custom apps platform support" is an unchecked box without an issue number (which is, apparently, this one).

November will be a short iteration...unless the demise of HockeyApp is put off for this (and the other remaining features).

So...how's it going?

@gautamkrishnar
Copy link

gautamkrishnar commented Oct 30, 2019

I think you guys should add a CI like platform that uses containers to execute jobs so that anyone can add their own custom tools via cli to build the projects. For example: if i need to use gcc i can install it from apt repository and do whatever operations i need on my app, i just need to specify the tasks and installation of dependencies via commands. This is the only way to support the infinite number of custom OSes.

@lbrownell-gpsw
Copy link

lbrownell-gpsw commented Oct 30, 2019

@gautamkrishnar That sounds like a good idea for the build side (and would lead to supporting web-based apps!).

But this ticket is -- to my mind -- mostly about being able to distribute built packages of one sort or another, that aren't standard (e.g., a compressed package full of stuff).

Speaking of which: The release_uploads POST api will play a key role in this.

BTW, it's Swagger page definition needs updating: It's a POST, but for "normal" packages, the POST data should be omitted -- however, in swagger, it says it is required (makes sense, a POST with no data? Odd).

You will HAVE to specify version and build number info for custom packages (and thus include the POST data); App Center will not be able to find them, UNLESS you mandate some kind of manifest be included with that specific info. Which would be fine, sort of, except for migrating old packages.

Now, about that api. Here's what it does now with your POST data:

  • If you include the post data, you need to specify all three values, even though release_id is ignored.
  • In your post, build_version and build_numberare used incorrectly:
    • It will complain that your version is isn't an integer (it should be a tuple; both parameters are strings, btw).
    • If you switch them, it will work -- but you'll end up with a build ID like 123(1.0.0) which is wrong.
    • If it can find build and version info in your package, it will produce an error if the info you provided doesn't match. This is good -- except, still switched (build needs to match version and vice versa).
    • HockeyApp used to do this as well -- it got it right when it extracted info from the package, but when you explicitly specified version and build, it swapped them.

This needs immediate attention.

I found this out trying to post a new Windows app we're building -- we decided to post this to App Center directly, avoiding HockeyApp. Following the Swagger instructions, I experimented until I got it to work, but noticed that the version/build were swapped as noted above.

I then tried posting without the POST data. That worked, but the build info is just 1.0.0 -- version number yes, build number no. This is our fault, not injecting the build number into the app package.

But we do have some custom apps that will need this to work!

The cli doesn't appear to have support for specifying version/build info at all.

Nov 16th!!!

UPDATE: The release_uploads API has been fixed, in that it no longer checks for either version or build number to be integers -- thus, you can set them as any string and they will be reported as such, in the fields you intended. Which is HUGE in supporting this ticket, yay!

Note that the swagger page still shows the body as required. It does show in the example as using 0 for release_id; I use 1, that works too.

@dipree
Copy link
Member

dipree commented Oct 30, 2019

@lbrownell-gpsw no worries, we're almost done and in case we're not on time, you won't lose anything and will still have access in HockeyApp.

From the docs:

It will take us a few months to complete the move of all apps. If your app is affected by any of the feature gaps listed on our public roadmap, we won't move them until the gaps are closed. HockeyApp will still be available until then. We recommend you to move your app immediately once it becomes unaffected.

@del314
Copy link

del314 commented Nov 4, 2019

So I am catching up here, but HockeyApp supported the upload for our Linux applications (.zip right now) under Custom OS, so I am hoping you guys get this supported on server (and CLI tool is necessary) BEFORE the transition completes. An ETA would be reassuring :)

On that note, I am not sure why you don't support a Linux OS type anyway, as it would be nice to support other installers like .rpm and .deb directly (although we can package inside zip for now).

@niezbop
Copy link

niezbop commented Dec 11, 2019

For documentation purpose, this appears to be supported as of today, at least.

We got a bit worried that our Linux projects got migrated automatically on a platform that wasn't supported (or so we thought).

It would be great if you could document such features becoming supported, closing this issue, and updating #1322 for example!

@dipree
Copy link
Member

dipree commented Dec 11, 2019

@niezbop the forwarding of crashes from the HockeyApp custom crash upload API wasn't fully completed yet but it is now.

Support for "Custom" OS is supported in App Center now. Please let us know in case you're experiencing any issues.

@dipree dipree closed this as completed Dec 11, 2019
@EmilAlipiev
Copy link

Last time I checked this it wasn't working. iMessage able to upload crash and event reports using the rest API but nothing was displayed in the AppCenter. When I asked the support they told me that it is not implemented. What is the status today?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature request hockeyapp Related to HockeyApp's transition to App Center
Projects
None yet
Development

No branches or pull requests