Fixup automatically created feed permissions#8037
Merged
Merged
Conversation
Tighten up the feed permissions used when creating new feeds on the fly, or when publishing signed assets, and do a bit of refactoring in the process. - Put internal feeds into the internal project, rather than the organization. This is where they should have been from the beginning. There was mainly confusion about project vs. org scoped feeds when this was created. - Tweak the default feed permissions so that: - Members of dnceng get read perms on the local view (this avoids an issue where we used to have to add people as Contributors). This is done by patching the local feed view after feed creation. - Admins get ownership - the internal and collection build service accounts get write access - Added some nice NYI exceptions that should fire if we ever change the organization or project that we are running in. - Update references to the task, in PublishSignedAssets.proj and SetupTargetFeedConfigV3, to use the new task parameters. Refactoring: - Remove SetupTargetFeeds.proj (v2 support), which is unused. I chose to do this because it also contain a reference to CreateAzureDevOpsFeed - Set the default publishing version to 3 - Remove IsInternal as a feed task creation parameter and replace it with the AzDO project. The AzDO project defines the visibility, and this cleans up a little of the dnceng-isms and enables moving them into some helper methods - Add helper methods for determining some aspects of the feed names - Refactor some variable names to make them clearer
Member
Author
mmitche
changed the title
ghost
approved these changes
Oct 13, 2021
epananth
approved these changes
Oct 13, 2021
When the new target feed specifications were created, they collapsed down the feed specs for shipping and non-shipping package asset selection in cases where the target would be the same feed. This subtlety was required though, since in case of a stable build, we want just the shipping packages to go to a separate, newly created feed. The current code correct substitutes this if the TargetFeedSpecifications are broken out for ShippingOnly and NonShippingOnly, but there are a number of channels that did not break them out. Instead, it tried to send shipping packages to the isolated feed, and all packages to the non-isolated feed. To fix this, separate out the TargetFeedSpecifications and put a check into the constructor to ensure that this can't be done accidentally. Also - Do a little refactoring for clarity. - Add a test to ensure that this throws
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tighten up the feed permissions used when creating new feeds on the fly, or when publishing signed assets, and do a bit of refactoring in the process.
Refactoring:
To double check: