The following diagram shows how a dependency update PR progresses from opening to merging. The flow is triggered when a subscription is triggered by a user or on a schedule.
flowchart
SubscriptionTrigger(Subscription is triggered)
Exist{Does a PR\nalready exist?}
State{What state\nis the PR in?}
PolicyState{What state\nare the check\npolicies in?}
Create(Create a new PR)
CleanUp((Clean up\nbranch))
TagPeople(Notify/tag people)
UpdatePR(Update PR,\nif possible)
MergePR(Merge PR)
UpdateLastBuild((Update\nLastAppliedBuild\nin BAR))
Timer(Periodic timer)
Exist--Yes-->State
Exist--No -->Create
SubscriptionTrigger-->Exist
State--Open-->PolicyState
State--Merged-->UpdateLastBuild
State--Closed-->CleanUp
PolicyState--Checks OK-->MergePR
MergePR-->UpdateLastBuild
PolicyState--Failed checks-->TagPeople
TagPeople-->UpdatePR
%% Cannot update
PolicyState--Pending policies-->Timer
%% Can update
PolicyState--Conflict-->UpdatePR
Timer--Check PR-->State
Create--Set timer-->Timer
UpdatePR--Set timer-->Timer
subgraph Legend
MaestroAction(Action)
ExternalImpulse(Trigger)
EndOfFlow((End of flow))
end
classDef Action fill:#00DD00,stroke:#006600,stroke-width:1px,color:#006600
classDef End fill:#9999EE,stroke:#0000AA,stroke-width:1px,color:#0000AA
classDef External fill:#FFEE00,stroke:#FF9900,stroke-width:1px,color:#666600
class Create,TagPeople,NoAction,UpdatePR,MergePR,MaestroAction Action
class UpdateLastBuild,CleanUp,EndOfFlow End
class SubscriptionTrigger,Timer,ExternalImpulse External
linkStyle 2,12 stroke-width:2px,fill:none,stroke:#FFEE00,color:#FF9900
The above flow only applies to the usual dependency flow updates (version files, etc.). The flow works a little bit different for the code-enabled subscriptions that flow code between product repos and the VMR. For those, the PR branch is created by the Product Construction Service.
flowchart
SubscriptionTrigger(Code-enabled\nsubscription triggered)
PRExists{Does a PR\nalready exist?}
BranchExists{Does a branch\n exist?}
CreatePR(Create a new PR)
PRState{What state\nis the PR in?}
CleanUp((Clean up\nbranch))
TagPeople(Notify/tag people)
UpdatePR(Call to PCS\nUpdate branch)
MergePR(Merge PR)
Timer(Periodic timer)
CreateBranch(Call to PCS:\nRequest PR branch)
PolicyState{What state\nare the check\npolicies in?}
UpdateLastBuild((Update\nLastAppliedBuild\nin BAR,\nclean up branch))
SubscriptionTrigger-->PRExists
PRExists--No -->BranchExists
PRExists--Yes-->PRState
BranchExists--Yes-->CreatePR
BranchExists--No -->CreateBranch
CreateBranch--PCS pushes a branch,\ntriggers the subscription-->SubscriptionTrigger
PRState--Open-->PolicyState
PRState--Merged-->UpdateLastBuild
PRState--Closed-->CleanUp
PolicyState--Checks OK-->MergePR
MergePR-->UpdateLastBuild
PolicyState--Failed checks-->TagPeople
TagPeople-->Timer
%% Cannot update
PolicyState--Not updatable PR\npending policies, conflicts.. -->Timer
%% Can update
Timer--Check PR-->PRState
CreatePR--Set timer-->Timer
UpdatePR--Set timer-->Timer
subgraph Legend
MaestroAction(Action)
ExternalAction(External call)
ExternalImpulse(Trigger)
EndOfFlow((End of flow))
end
classDef Action fill:#00DD00,stroke:#006600,stroke-width:1px,color:#006600
classDef End fill:#9999EE,stroke:#0000AA,stroke-width:1px,color:#0000AA
classDef External fill:#FFEE00,stroke:#FF9900,stroke-width:1px,color:#666600
classDef PCSCall fill:#DD0000,stroke:#660000,stroke-width:1px,color:#ffffff
class CreatePR,TagPeople,NoAction,MergePR,MaestroAction Action
class UpdateLastBuild,CleanUp,EndOfFlow End
class SubscriptionTrigger,Timer,ExternalImpulse,PCSFinished External
class CreateBranch,UpdatePR,ExternalAction PCSCall
For any non-deployment code changes, the expectation is to have run the tests corresponding to the service locally to confirm that the change works before putting up the PR. The tests for each of the major areas in arcade-services are as below:
For any deployment changes, the only way to test would be to kick off the build pipeline that deploys the intended service from the dev branch to staging / int environment.
⚠️ 😓 💥
This comes with a significant overhead of a possibility of leaving the int deployments in a broken or non-responsive state, which then would require significant manual effort to undo the damage especially with the Service Fabric Clusters. This process should only be done if and only if absolutely necessary and after obtaining management approval.
Steps:
-
Run the
arcade-official-cipipeline (based onazure-pipelines.yml) from your dev branch. -
Once the testing is done, rerun the pipeline for main branch to return the deployment to a last known good.
Each of the links on the left side bar represent a channel for a product. Clicking on one of these links will load the current build state for a channel.
The two main states of a channel’s current build are as follows:
-
✅ Current build is good.
-
⚠️ There are issues with this build. The message at the top of the build's page will give you more information as to the issue, but most likely is one of the following issues:- The repository is not running the latest version of the Arcade toolset. Older versions of the Arcade toolset are incompatible with determining the state of the build.
- Latest builds are failing
While looking at a build, you may notice highlighted (in yellow) dependencies. These denote the dependencies that are an older version than another of the same dependency used in the build. This should help the teams to identify issues with dependency coherency within a build.
When mousing over a dependency, you may notice icons that show up along the left-hand side of the list. The icon at the top of the column provides help for understanding these icons. These icons are to assist in understanding the hierarchy of the dependency graph and to point out conflicting dependencies within the build.
The number at the top of the build's page, next to the URL for the repository, is the current build number of the repository. The link of the hash below the URL will take you to the AzDO repository and the hash referenced so that the user can see all the commits that are a part of the latest build.
Similarly, each dependency denotes the version of that dependency used and a link to the hash of the latest commit that was contained in the build.
If you would like to see your repository on BARViz, it needs to be published to the Build Asset Registry. Please see the Darc documentation.