Polish Azure Pipelines build

[sormuras]

After-math for #1807 and closes #1795.

Deliverables

• Provide credentials to publish SNAPSHOT assets (artifacts and documentation)
• Update https://github.com/junit-team/junit5/blob/master/README.md#continuous-integration-builds table with shields pointing to Azure Pipelines
• Configure "Publish Test Results Job" to include only propery results: azure-pipelines: more complete port of travis conf #1807 (comment)
• Configure "Checkout task" to only checkout the current branch
• The two last jobs (publish snapshot assets) should only start if "Linux (JDK 11)" was successfully executed
• Remove AppVeyor configuration
• Uninstall/disconnect AppVeyor service
• Remove Travis CI configuration
• Uninstall/disconnect Travis CI service
• Configure dependency cache on Azure Pipelines will be done in Configure dependency cache on GitHub Actions #1826

[sormuras]

/cc @ethomson @brunoborges

[sormuras]

Added the "overall pipeline status badge" via

It is possible to show off all (or some) jobs in a table:

• Linux (OpenJDK 11) 🤜
• Linux (OpenJDK 12) 🤜
• Linux (OpenJDK 13) 🤜

[sormuras]

Click Advanced settings in the Get Sources task to see some of the above options.

I can't find the "Advanced settings..." described here https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops to activate the "Shallow fetch" option.

[ethomson]

I can't find the "Advanced settings..." described here https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops to activate the "Shallow fetch" option.

Sorry for the confusion - we have two independent ways to configure CI, either the visual designer or the YAML. It's pretty much all or nothing (all visual designer or all YAML) and those instructions guide you to the visual designer path. We're using YAML which is right and true, so I opened #1812 to add the shallow clone rules to the YAML.

[sormuras]

Understood.

We are trying to insert our secret credentials via UI right now. Looking forward to merge #1812 and proceed with the switch.

[sormuras]

Current status

Todo

• The two last jobs should only start if the five above were successfully executed.

[ethomson]

The two last jobs should only start if the five above were successfully executed.

Should be something like:

- job: publish_artifacts
  displayName: Publish Snapshot Artifacts
  dependsOn:
  - linux_11
  - linux_12
  - Mac
  - Windows
  - coverage

@sormuras I can send a PR unless you're in the middle of this.

[sormuras]

About to push it in a second... ;-)

[sormuras]

See 6706691 ... chose linux_11 as single dependency for now.

[sormuras]

"Not started" as expected...

[sormuras]

@ethomson ... those two publish/update jobs (and the coverage job as well) are good candidates for a dedicated "Release Pipeline", aren't they?

[ethomson]

those two publish/update jobs (and the coverage job as well) are good candidates for a dedicated "Release Pipeline", aren't they?

@sormuras - I actually would not in this case. There's a couple of reasons:

1. Pipelines are really useful when you have additional levels of complexity. For example: if you want to deploy to a staging server, then QA, then production, pipelines help manage that. They're still useful for a single deployment like this but you're not taking advantage of a lot of the complex parts.

2. It also adds a complication, related to the first point: since pipelines are created for a way to arbitrarily deploy artifacts, you need to build an artifact. So you'll probably run ./gradlew --scan publish -x check then zip up the artifacts and publish them. Then your release pipeline will take that zip and do the publish. So it's slower and has another moving piece.

3. Release pipelines can't be defined as YAML (yet).

So, to be honest, I would keep this as-is for now, it's simpler and gets the job done. If you want to scale things up or increase the complexity then it makes sense to reconsider.

[sormuras]

Keeping things as-is. Thanks for the details.

[sormuras]

Updated deliverables with "clean up" entries.

[sormuras]

Performance comparison

• Travis 9 minutes 14 seconds
• Azure 9 minutes 7 seconds

But

• Travis spent 10 seconds to restore cached /home/travis/.gradle/caches scan
• Azure spent 2 minutes 24 seconds on downloading plugins and dependencies scan

[sormuras]

Caching is not yet supported at Azure Pipelines: https://devblogs.microsoft.com/devops/adding-caching-to-azure-pipelines/

[ethomson]

[marcphilipp]

I guess we could build our own Docker image with a "pre-warmed" cache but it's probably not worth the complexity.

[sormuras]

Let's wait for ... "SOON".

[sormuras]

"Publish" jobs were executed although "Build+Test" jobs failed?

https://dev.azure.com/junit-team/junit5/_build/results?buildId=59

[ethomson]

"Publish" jobs were executed although "Build+Test" jobs failed?

Sorry, that's my fault. I thought it was an accurate translation of the Travis but I may be wrong. Either way I didn't think through the logic very well. 😝

We should just need a succeeded() conditional, I can send a PR.

[marcphilipp]

We'll look into caching dependencies in #1826.