Opened 3 years ago

Closed 3 years ago

#4549 closed change (fixed)

Implement the Windows Store API to upload development builds

Reported by: sebastian Assignee: oleksandr
Priority: P2 Milestone:
Module: Sitescripts Keywords:
Cc: kvas, oleksandr, wspee, trev Blocked By:
Blocking: #4626 Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

https://codereview.adblockplus.org/29374637/

Description (last modified by sebastian)

Background

For Chrome and Firefox, the development builds are automatically generated and submitted to the respective stores, once new changes landed in the repository. However, for Microsoft Edge, development builds are still generated and published manually.

What to change

Implement the Windows Store API in order to automatically upload development builds for Microsoft Edge, similar to how we did it for the Chrome Web Store.

Since the Windows Store requires the fourth part of the version number to be 0 (see below), the revision number should replace the third part, instead of being added as fourth part like we do for other devbuilds.

Change History (18)

comment:1 Changed 3 years ago by kvas

  • Owner set to kvas

comment:2 Changed 3 years ago by jsonesen

  • Blocking 4626 added

comment:3 Changed 3 years ago by sebastian

  • Cc wspee trev added
  • Owner changed from kvas to sebastian

I unassigned kvas, who didn't start to work on this issue yet and is on vacation now. However, wpsee told me that he might be interested to work on this. ;)

But at least one more thing we need to agree on, is the version scheme of development builds for Microsoft Edge. So far our development builds use version numbers consisting of 4 parts (e.g. 1.12.4.1702) where the last part is the revision number from Mercurial. However, as it turned out meanwhile, the Windows Store requires all version numbers to have 4 parts where the last part must be 0 (it is meant for internal use by the Windows Store). The probably most pragmatic approach would be to just ignore the third part for development builds for Microsoft Edge, so Adblock Plus for Chrome 1.12.4.1702 would be equivalent to Adblock Plus for Microsoft Edge 1.12.1702. Or we could take this opportunity, to simplify our version numbers all together, so that release versions have only 2 parts, and development versions 3 parts (with the last one being the revision), for all platforms or at least those based on adblockpluschrome (for now).

Last edited 3 years ago by sebastian (previous) (diff)

comment:4 Changed 3 years ago by sebastian

  • Owner sebastian deleted

comment:5 Changed 3 years ago by oleksandr

I wouldn't mind working on this as well. Also, I think just ignoring the third part in our versioning is good enough.

comment:6 Changed 3 years ago by wspee

I don't really mind. Is this something that is needed for the upcoming edge release? Then it might be better to let @oleksandr do it? On the other hand he might have a lot to do already?! Either way just let me know.

comment:7 follow-up: Changed 3 years ago by sebastian

  • Description modified (diff)

I don't mind who is going to work on this. Though somewhat important, it is not ridiculously urgent. We'd just have keep preparing development builds manually, as we did so far for Microsoft Edge, until this has been implemented. Also it probably won't be any quicker dependent on who of you are working on it, as both of you seem to not be too familiar with our sitescripts and buildtools. ;)

I am not too happy with the situation with the version number, but nobody seems to have any better idea. So I updated the description accordingly, so that we replace the third part of the version number.

comment:8 in reply to: ↑ 7 Changed 3 years ago by oleksandr

I can find other stuff to work on. I just wanted to make sure we'll get Edge devbuilds from adblockpluschrome ASAP, so thought I might help out here. If you're fine doing it manually then the priority of this is not really P2, I guess.

comment:9 Changed 3 years ago by sebastian

Of course the current situation isn't great, and something we should tackle soon. But it's not that there is much we can do to speed it up, in particular with the upcoming holiday season. However, before this is going to block anything, we have at least the option to manually publish a development build if necessary. Anyway, I guess, whoever of you gets first the chance to start working on this, just assigns the issue to himself.

Last edited 3 years ago by sebastian (previous) (diff)

comment:10 Changed 3 years ago by oleksandr

Whoever starts working on it will need tenant ID, client ID and key based on documentation here: https://msdn.microsoft.com/en-us/windows/uwp/monetize/create-and-manage-submissions-using-windows-store-services#obtain-an-azure-ad-access-token

An Azure Active Directory Global Administrator should be able to retrieve that. Sebastian, would you be able to retrieve it?

comment:11 Changed 3 years ago by sebastian

I gave you the Manager role in the Windows Store, for now. As far as I understand, you should be able to retrieve those data yourself, now.

comment:12 Changed 3 years ago by oleksandr

  • Owner set to oleksandr

comment:13 Changed 3 years ago by oleksandr

Our Azure account is not allowed to automate Windows Store submissions through the API. See the paragraph here:

Important

This API can only be used for Windows Dev Center accounts that have been given permission to use the API. This permission is being enabled to developer accounts in stages, and not all accounts have this permission enabled at this time. To request earlier access, log on to the Dev Center dashboard, click Feedback at the bottom of the dashboard, select Submission API for the feedback area, and submit your request. You'll receive an email when this permission is enabled for your account.

Currently I am getting an error 'Authorization: Account is not allowed to access this api'. I have submitted a request to enable the API for us, but did not receive any results yet.

comment:14 Changed 3 years ago by oleksandr

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:15 Changed 3 years ago by abpbot

comment:16 Changed 3 years ago by oleksandr

  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:17 Changed 3 years ago by sebastian

  • Resolution fixed deleted
  • Status changed from closed to reopened

The devbuild that has just been published by the automation has the version number 0.9.10.0. This version number doesn't contain the source control revision. So once the next commit is pushed, and a new devbuild is created, it would have the same version number.

As discussed above, due to limitations of the Windows Store, the version number must have have exactly 4 parts, with the fourth part always being 0. Hence, we agreed, as specified in the description of this issue, to replace the third part with the revision, i.e. 0.9.1727.0.

If this should no longer be necessary the version should be 0.9.10.1727. Either way, it is essential to have the revision in the version number of devbuilds.

comment:18 Changed 3 years ago by sebastian

  • Resolution set to fixed
  • Status changed from reopened to closed

According to Ollie, the actual version number is 0.9.10.0.1727, merely in the Windows Store developer login (where I have checked), the version number is truncated. Sp this should be fine.

Note: See TracTickets for help on using tickets.