Publish Azure DevOps CI build `target` output folder as artifact

[icnocop]

Expected Behavior:

I expected to be able to download the contents of .\target\Release\docfx from Azure DevOps CI builds from https://docfx.visualstudio.com/docfx/_build.

For example, I would like to download and use a pre-release version without having to pull and build the code myself.

Actual Behavior:

I cannot download the build artifacts.

If azure-pipelines.yml was checked in, I can update and test it with the additional task, something like:

    - task: PublishBuildArtifacts@1
      condition: always()
      inputs:
        pathtoPublish: 'target\Release\docfx'
        artifactName: target

Thank you.

[superyyrrzz]

I agree it can save your local build time if you can download artifacts, but I am thinking the PR build is mainly used to validate the change by build and test. The process may be like local build => test => creating PR, while publishes artifacts looks like reverse the process...

[icnocop]

Thank you for your consideration.

I'd like to download the CI builds from the dev branch for example, not necessarily PR builds.

After a PR has been merged, a CI build is triggered.

There may be other PRs merged, so the build may be different than what's on my local machine.

If a bug fix has been checked in recently, by someone else for example, I'd like to be able to download the latest build and test it with my project.

There may also be environmental differences between a local build and one from the CI build, and having the CI build available to download may eliminate some variables when troubleshooting issues.

Can the azure devops yaml file be made available?

Thank you.

[superyyrrzz]

@icnocop Thank you for your ideas. We have a stable branch, which usually is same with dev branch. It publishes the package to a public Nuget feed https://www.myget.org/F/docfx-dev/api/v3/index.json. You can see it in the table stable-package.

It seems good to make the YAML file available. BTW, if you can already access the package in this feed, is this requirement urgent to you?

[icnocop]

Thank you for pointing me to the "Build Status" table and providing me with the public MyGet Nuget feed for docfx-dev.

I was able to use the docfx.console Nuget package using the feed https://www.myget.org/F/docfx-dev/ and this satisfies my current requirements, so this issue is not urgent.

I'm wondering what criteria is met before the code gets pushed from the dev branch to the stable branch and why can't builds from the dev branch just be published to the myget feed instead? In this way, someone doesn't have to "wait" for a daily build. When does a daily build from the stable branch get triggered? It seems that the dev branch is a mirror of the stable branch and I'm basically wondering why the stable branch is needed at all?

In any case, there are some issues with the "Build Status" table links:

1. The master and stable Azure pipeline build status badge links return 401 Not Authorized Sorry, but <my email address> is not authorized to access this page
2. The stable MyGet NuGet package feed badge link just redirects me to https://www.myget.org.

Similar issues exist in the "Running Status" table links: The Windows with .NET Core v2.0.3 and Windows with VS2017 Azure pipeline build status badge links return 401 Not Authorized.

Thank you!

[superyyrrzz]

It is related to our development model. We usually release every 3 weeks (a sprint). dev = stable in the first 2 weeks, but we will stop syncing from dev to stable in the last week to avoid last minute change. So the criteria are just timing issue.

I did feel stable is not necessary currently, as we have not as many commits as before. We will abandon stable to avoid confusion.

The nightly build on stable branch triggers at 21:00 GMT on every working day.

For 401 issue, it is because this project on Azure DevOps is not a public one. For MyGet issue, it need the private account to access the web UI. So current only the badge link is useful for public users.

[superyyrrzz]

@icnocop Thank you for the suggestion. We plan to change accordingly next week.

BTW, as you are using DocFX's PDF feature, we are curious what is your user scenario? How do you host the generated PDF file?

[icnocop]

Thank you for the update; that's great news! :)

In my scenario, users have the option to read the docs online or download a PDF file to read offline. The PDF can also be sent as an attachment in an email for example.

The PDF file is hosted on the same web server as the generated HTML help docs. The web server could be the public cloud instance or on-premise. The web server in the public cloud is currently running on AWS Cloudfront. The web server on-premise is on the client/customer's machine running Windows and is usually either IIS or a standalone web server like CassiniDev.

I hope that answers your questions.