Skip to content

Add new private channel publishing guardrails #14167

Open
@mmitche

Description

  • This issue is blocking
  • This issue is causing unreasonable pain

As extra insurance, Arcade publishing should refuse to publish to public endpoints if the commit being published is not anonymously accessible. I could see this implemented in a couple ways:

Darc

  • Darc would attempt to anonymously access to commit of the BAR build id that is about to be published. This would happen locally as well as in CI automation, assuming that a local dev has updated their darc client.
  • If the commit is anonymously accessible, any channel is permissible
  • If the commit is not anonymously accessible, only internal channels are permissible.

Because publishing endpoint data is kept in arcade, this would require some kind of DB addition. On that note, I don't love it.

Arcade

  • The maestro publishing logic would attempt to anonymously access to commit of the BAR build id that is about to be published.
  • For all channels to be published to, if any are public (this metadata is on the channel config) and the commit is not anonymously accessible, we fail.

This method does have one annoying side effect. Dev builds of branches pushed only to AzDO (e.g. for testing arcade changes) would not be able to be published to the public "General Testing" channel. I propose that this would be deal with by adding an override switch to darc that would explicitly pass the "SkipSafetyChecks" parameter to the build task.

Verdict

I think going with the arcade publishing method is best.

Release Note Category

  • Feature changes/additions
  • Bug fixes
  • Internal Infrastructure Improvements

Release Note Description

Metadata

Assignees

Labels

Ops - Service MaintenanceUsed to track issues related to maintaining the services .NET Eng Supports

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions