Add github workflow for Azure

[mohit038-zz]

fixes #215

[mohit038-zz]

@tobiasdiez, Please change the index document name from the default index.html to taskpane.html in the Azure portal.

see the 6th point.
https://docs.microsoft.com/en-us/office/dev/add-ins/publish/publish-add-in-vs-code#using-visual-studio-code-to-publish

[tobiasdiez]

In contrast to "Azure Storage" apps, "Static Web Apps" don't seem to have this option. I've found Azure/static-web-apps#232 which discusses the same issue and recommends to add an empty index.html. Could you please try this?

[tobiasdiez]

But maybe it's already enough to change

JabRef-Word-Addin/webpack.config.js

Line 76 in 4377c36

filename: "taskpane.html",

to use index.html instead of taskpane.html, and change the reference in the manifest at the same time. Not sure if the entry pane has to be called taskpane.

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://lively-ground-0d7c50410-216.centralus.azurestaticapps.net

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://lively-ground-0d7c50410-216.centralus.azurestaticapps.net

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://lively-ground-0d7c50410-216.centralus.azurestaticapps.net

[tobiasdiez]

Nice!

I just tried to follow https://docs.microsoft.com/en-us/office/dev/add-ins/testing/create-a-network-shared-folder-catalog-for-task-pane-and-content-add-ins to test if one could sideload the staged build in Word. However, the address in the manifest points to localhost and not to the (changing) azure staging address. Don't know what's the best way to fix this. The obvious choices of a) having a fixed staging web address or b) transforming the manifest during build to inject the correct address don't seem to be possible right now Azure/static-web-apps#22 Azure/static-web-apps#537.
What could work is to use the output of the deployment https://github.com/Azure/static-web-apps-deploy/blob/0407e359a606e89151694428fa2457e4ef646693/action.yml#L44, transform the manifest file and then do another deployment including the new manifest. Sounds very awkward. Anyway, that's something for a new PR.

[mohit038-zz]

Transform the manifest file and then do another deployment, including the new manifest

We don't need to host the manifest file on the server. This file just points to the location where the addin is hosted. And this shared catalog folder thing is like a shared google drive folder that can only be shared with Windows users. So my suggestion is to create a google drive folder and put the updated manifest file in that folder so that everyone can access it.

And another advantage of using a drive folder is that even if our staging web address changes, we can easily update the web address in the manifest file.

I just tried to follow https://docs.microsoft.com/en-us/office/dev/add-ins/testing/create-a-network-shared-folder-catalog-for-task-pane-and-content-add-ins to test if one could sideload the staged build in Word.

I tried it with the updated link, but I got an error because the addin is still not connected with jabref online. It should work after the API azure function is implemented.

Edit: Sorry, I didn't know that link changes every time a commit is pushed, I'd suggest we have a stable link in that case if that's possible.

[k3KAW8Pnf7mkmdSMPHz27]

Edit: Sorry, I didn't know that link changes every time a commit is pushed, I'd suggest we have a stable link in that case if that's possible.

I think it just changes for every PR. I'll keep on looking at option b,

b) transforming the manifest during build to inject the correct address

and here are some links for now 😛

• The deployment URL has a specific form, only the PR number should change
• More information about how to get the pull-id is in the link Tobias provided above and on the GitHub side in Get pull request number from action actions/checkout#58
• Perhaps it is easier using something like https://github.com/marketplace/actions/find-current-pull-request

[tobiasdiez]

Ohh, I didn't realized that the URL is essentially constant except for the PR id. That's a super nice finding @k3KAW8Pnf7mkmdSMPHz27!

So in this case, the github action can indeed construct the correct path and inject it into the manifest file before uploading. Then one can simply test the PR by sideloading something like https://lively-ground-0d7c50410-216.centralus.azurestaticapps.net/manifest.xml

[k3KAW8Pnf7mkmdSMPHz27]

Perhaps updating the manifest can be done with https://github.com/marketplace/actions/edit-xml