ICU-22314 Refactor Azure CI into workflows conditional on modified paths

[echeran]

I am guessing that this would need some special configuration on the Azure side in order to recognize these new workflow files and give them an official display name.

Checklist

• Required: Issue filed: https://unicode-org.atlassian.net/browse/ICU-22314
• Required: The PR title must be prefixed with a JIRA Issue number.
• Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
• Required: Each commit message must be prefixed with a JIRA Issue number.
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable

[markusicu]

looks plausible; @rp9-next ?

[markusicu]

@rp9-next @jefgen @daniel-ju @erik0686 @jalaj-microsoft could you please take a look at this? It should reduce our CI time and resources significantly. tnx

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[rp9-next]

lgtm

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[rp9-next]

@echeran I merged above triggers, renamed existing CI pipeline and created a new pipeline for ICU4J inside ADO dashboard.

I created two draft PRs for testing.
#2830
#2831

However, in both I can see that only the CI-ICU4C(erstwhile CI) pipeline is triggered and the newer one is not triggerd.
I couldn't find any other settings on the ADO dashboard. I think there could be some pipeline triggers that are configured from GitHub repo settings whenever a PR is created that I do not have access to change.

Could you check once ?

+cc @markusicu, @jefgen

[markusicu]

@echeran I merged above triggers, renamed existing CI pipeline and created a new pipeline for ICU4J inside ADO dashboard.

I created two draft PRs for testing. #2830 #2831

However, in both I can see that only the CI-ICU4C(erstwhile CI) pipeline is triggered and the newer one is not triggerd. I couldn't find any other settings on the ADO dashboard. I think there could be some pipeline triggers that are configured from GitHub repo settings whenever a PR is created that I do not have access to change.

Could you check once ?

+cc @markusicu, @jefgen

Sorry, I have no idea where to look.

• @erik0686 @daniel-ju @mihnita

[echeran]

@rp9-next I took a look into the settings and went through a few different hypotheses. I can only rule out 1. The other hypotheses will require either you taking a look or us working together.

1. (not likely the cause) There is different syntax for Azure Pipelines for PRs vs. when you merge a PR ("PR triggers" vs. "CI triggers"). So I created ICU-22314 Add PR triggers for Azure pipelines #2835 to properly add triggers to the pipelines for PRs (even though the previous pipeline's syntax worked just fine on PRs and post-PR-merge commits without needing this change). I created test PRs for ICU4C and ICU4J, but I don't think I see a difference in behavior. I then looked at the file path filter pattern syntax because according to the docs, Azure DevOps Server (ADO) only supports wildcards (ex: * in icu4j/*) in version 2022+, but not in 2020 or earlier. Removing the /* from icu4j/* didn't make a difference, either. The CI-ICU4C pipeline is recognized, and is executed only in the PR that touches ICU4C code, but the CI-ICU4J pipeline is never executed, and it is not visible in the Github admin settings for the branch protection rules in the same way that CI-ICU4C is visible.
2. Maybe the CI-ICU4J pipeline does not have permissions enabled to be publicly visible to the ICU Github repository? In the Azure project for ICU, it seems like there are multiple pipelines, but only some of them are run automatically, while the rest are ignored. The ignored pipelines seem to have been made for testing purposes. The Github Azure app has all of the permissions its needs from the ICU GH repo.
3. Maybe there needs to be a one-time initialization of the new pipelines? According to the instructions for Azure Devops (ADO) on configuring pipelines to run for a Github repository, it says:

   If the repo is in a GitHub organization that you own, at least once, authenticate to GitHub with OAuth using your personal GitHub account credentials. This can be done in Azure DevOps project settings under Pipelines > Service connections > New service connection > GitHub > Authorize. Grant Azure Pipelines access to your organization under "Organization access" here. You must be added as a collaborator, or your team must be added, in the repository's settings under "Collaborators and teams".

Hypothesis number 2 is something you can look at on your own and confirm. If that is not the problem, then let's work on investigating hypothesis 3 together.

It is good to figure this out. Thankfully, the Azure CI jobs for ICU4J so far seem to be similar to our existing Github Actions jobs for ICU4J, so we have test coverage for now. But in the future, if we want to have Microsoft/Windows-specific Java tests, etc., then this will become an urgent problem. Let's fix this soon before it becomes a real problem.

[rp9-next]

Thanks @echeran for looking into this.
I merged #2835 and now I find that the pipelines are triggering normally as they should after creating the PRs..

#2830 #2831
I see that for ICU4J changes, the ICU4C build is rightly skipped. (It gets triggered for ICU4C changes)

I looked into hypothesis number 2 and ICU4J build is also triggered in the pipelines sections now! (I got access to enable the trigger after changes for the icu4j yaml got merged): https://dev.azure.com/ms/icu/_build?definitionId=629

For hypothesis number 3, I authorized the new pipeline while creating and linking it to the icu4j YAML file, so that should be covered already.

It seems the only remaining item is for CI-ICU4J to appear in the list of checks in the GitHub PR. Do you have any insights on how we can accomplish that?

[echeran]

As far as getting CI-ICU4J into the list of checks required for a PR targeting main and maint/*, I can configure it in the repo's settings under Branches > Branch Protection Rules. The UI for this is peculiar: there is a text box with a prompt that says: "Search for status checks for the last week for this repository". As you start typing, it dynamically updates an autocomplete dropdown list. I was able to use this yesterday to change CI to CI-ICU4C to get Fredrik's and others' PRs unstuck. After the PR merge, I don't see CI-ICU4J appearing yet.

Maybe we need to give it some time? Maybe another PR with Java changes needs to come around and trigger the check before it can be detected?

The fact that we have the CI-ICU4J pipeline set up properly in Azure Pipelines and being triggered automatically by Github PRs seems like the hard part. Let's make sure to keep track and get this require check configure because this is important to get the full benefit of all the work.