You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code flow model for code flowing from product repos to the VMR after the first Unified Build deliverable (.NET 10 timeframe) will end up looking like this:
Product repo merges a PR (in GitHub)
Commit is mirrored to Azure DevOps repo
Official build of the repo is started
Repository might be built (to verify the commit is fine) but not necessarily as packages will be built in the VMR
Build is registered in BAR and assigned to a channel
Code flow subscription is triggered from the channel to VMR and PR with code changes is opened in the VMR
Technically, step 4. can be a very quick operation - a no-op build that just needs to ping Maestro. But it still requires YAML, some tooling, an agent to boot etc. Maybe we could skip this step?
Goal
Explore how we could trigger forward flow updates without the need to queue an official build.
Example: Maestro watches for push commit events and acts on these directly. Or maybe the mirroring service pings Maestro.
Create a design with a proposal for a possible north-star the code flow should aim for.
The design should also mention possible intermediate milestones and how to reach the end state.
The text was updated successfully, but these errors were encountered:
Technically, step 4. can be a very quick operation - a no-op build that just needs to ping Maestro. But it still requires YAML, some tooling, an agent to boot etc.
Context
The code flow model for code flowing from product repos to the VMR after the first Unified Build deliverable (.NET 10 timeframe) will end up looking like this:
Technically, step
4.
can be a very quick operation - a no-op build that just needs to ping Maestro. But it still requires YAML, some tooling, an agent to boot etc. Maybe we could skip this step?Goal
Example: Maestro watches for push commit events and acts on these directly. Or maybe the mirroring service pings Maestro.
The design should also mention possible intermediate milestones and how to reach the end state.
The text was updated successfully, but these errors were encountered: