Re: [edk2-devel] RFC for Edk2-ToolEnv
Hi Sean, The edk2-pytool-extensions repo has been created. Thanks, Mike From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Sean via Groups.Io Sent: Friday, June 28, 2019 3:14 PM To: Sean ; devel@edk2.groups.io Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv Wrapping up all comments on the RFC and requesting the RFC move to the implementation phase. Changes after community discussion: 1. GitHub repository will be called edk2-pytool-extensions 2. An additional comment will be added to the contribution process to make it clear that PRs will be squashed and therefore patch-sets are not supported and it is best to create smaller individual pull requests. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#43040): https://edk2.groups.io/g/devel/message/43040 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Both of these RFCs listed flake8 because that is what we have today and it should be relatively easy to get parity. I am super happy to have you add/propose/provide pr with additional test capability like Pylint. Thats one of the goals of adding this to tianocore. You can see what we are basing this on here: https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=10 And you can see how the build works in the Azure DevOps yaml file: https://dev.azure.com/projectmu/mu%20pip/_apps/hub/ms.vss-build-web.ci-designer-hub?pipelineId=10=BIDKbQdfN9%2BmJevdri5mWw%3D%3D=master ( https://dev.azure.com/projectmu/mu%20pip/_apps/hub/ms.vss-build-web.ci-designer-hub?pipelineId=10=BIDKbQdfN9%2BmJevdri5mWw%3D%3D=spbrogan=master ) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42257): https://edk2.groups.io/g/devel/message/42257 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Hi Sean , Sorry I replied to wrong subject and it's about ToolEnv. It's great that all python files must pass flake8 Python Style. I remember flake8 does not show errors for undefined member variables or instances . I feel this is one of most common use cases of code failures, due to typing errors and won't be visible unless test that use case. Are we planning to use any flake8 plug-ins to cover this or is it good idea to use Pylint (only to cover features not covered by falke8)on top of flake8. Thanks, Kondal. -Original Message- From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Michael D Kinney Sent: Thursday, May 23, 2019 10:14 AM To: devel@edk2.groups.io; sean.bro...@microsoft.com; Kinney, Michael D Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv Hi Sean, Thanks for the clarification that this PIP module has more than just build and CI. And over time, it may add more features to help developers maintain their code and platforms. How about edk2-tool-extensions And we perhaps remove plural from the library repo edk2-tool-library Do you think that python needs to be in the repo name so it is obvious these are python components. Or is the top level Readme.md sufficient to make this obvious. Perhaps: edk2-pytool-extensions edk2-pytool-library Mike > -Original Message- > From: devel@edk2.groups.io > [mailto:devel@edk2.groups.io] On Behalf Of Sean via Groups.Io > Sent: Wednesday, May 22, 2019 11:46 PM > To: Kinney, Michael D ; > devel@edk2.groups.io > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv > > Yes the plan would be to support both CI and local builds. There is > actually more features related to support platform builds so I think > it would be better to keep ci out of the name. The reason why > Tool-Env was suggested is the modules can be used to run anything > within the python environment not just builds. > We have a git submodule update tool, external dependency management > tool (package mgmt/binary files), platform build tool, and CI build > tool. > > Look at https://github.com/microsoft/mu_pip_environment > and https://github.com/microsoft/mu_pip_build to get an idea of the > content proposed. > > Thanks > Sean > > > > -Original Message- > From: Kinney, Michael D > Sent: Wednesday, May 22, 2019 7:39 PM > To: devel@edk2.groups.io; rebe...@bluestop.org; Sean Brogan > > Subject: RE: [edk2-devel] RFC for Edk2-ToolEnv > > Hi Sean, > > Does the PIP module here support both local platform builds and CI > builds? > > I am looking at the name of the repo and trying to align with the > edk2-tools-library repo name so it is obvious the two repos are > related. Maybe focus on the CI part for the name and we reuse the CI > features to simplify local builds. > > edk2-tools-ci > > Finalizing the name is the only open I am aware of. > > Thanks, > > Mike > > > -Original Message- > > From: devel@edk2.groups.io > [mailto:devel@edk2.groups.io] On Behalf Of > > rebe...@bluestop.org > > Sent: Tuesday, May 14, 2019 4:34 PM > > To: Sean ; devel@edk2.groups.io > > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv > > > > On 2019-05-14 17:23, sean.brogan via groups.io wrote: > > > Take a look at the proposed content and how it is > > used. We even have > > > examples of calling from DevOps and i don't think > > Jenkins would be any > > > different. I don't think we are trying to > duplicate CI > > > functionality. We are providing the "last mile" so > > that those CI > > > engines can run EDK specific tests and > tools. Standard > > CI engines > > > have no concept of packages, DSC, FDF, INFs, > firmware, > > etc. > > > > > > Okay, that's great. Of course we do also have lots of > code running on > > the CI server at work, not the client, that does > things like packaging > > etc., and this proposal will include server-side code > too. > > > > Also, I don't think there is anything that'll be as > nicely integrated > > as this, so I'm happy with it. > > > > > > -- > > Rebecca Cran > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42223): https://edk2.groups.io/g/devel/message/42223 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Hi Sean, Thanks for the clarification that this PIP module has more than just build and CI. And over time, it may add more features to help developers maintain their code and platforms. How about edk2-tool-extensions And we perhaps remove plural from the library repo edk2-tool-library Do you think that python needs to be in the repo name so it is obvious these are python components. Or is the top level Readme.md sufficient to make this obvious. Perhaps: edk2-pytool-extensions edk2-pytool-library Mike > -Original Message- > From: devel@edk2.groups.io > [mailto:devel@edk2.groups.io] On Behalf Of Sean via > Groups.Io > Sent: Wednesday, May 22, 2019 11:46 PM > To: Kinney, Michael D ; > devel@edk2.groups.io > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv > > Yes the plan would be to support both CI and local > builds. There is actually more features related to > support platform builds so I think it would be better > to keep ci out of the name. The reason why Tool-Env > was suggested is the modules can be used to run > anything within the python environment not just builds. > We have a git submodule update tool, external > dependency management tool (package mgmt/binary files), > platform build tool, and CI build tool. > > Look at https://github.com/microsoft/mu_pip_environment > and https://github.com/microsoft/mu_pip_build to get an > idea of the content proposed. > > Thanks > Sean > > > > -Original Message- > From: Kinney, Michael D > Sent: Wednesday, May 22, 2019 7:39 PM > To: devel@edk2.groups.io; rebe...@bluestop.org; Sean > Brogan > Subject: RE: [edk2-devel] RFC for Edk2-ToolEnv > > Hi Sean, > > Does the PIP module here support both local platform > builds and CI builds? > > I am looking at the name of the repo and trying to > align with the edk2-tools-library repo name so it is > obvious the two repos are related. Maybe focus on the > CI part for the name and we reuse the CI features to > simplify local builds. > > edk2-tools-ci > > Finalizing the name is the only open I am aware of. > > Thanks, > > Mike > > > -Original Message- > > From: devel@edk2.groups.io > [mailto:devel@edk2.groups.io] On Behalf Of > > rebe...@bluestop.org > > Sent: Tuesday, May 14, 2019 4:34 PM > > To: Sean ; > > devel@edk2.groups.io > > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv > > > > On 2019-05-14 17:23, sean.brogan via groups.io wrote: > > > Take a look at the proposed content and how it is > > used. We even have > > > examples of calling from DevOps and i don't think > > Jenkins would be any > > > different. I don't think we are trying to > duplicate CI > > > functionality. We are providing the "last mile" so > > that those CI > > > engines can run EDK specific tests and > tools. Standard > > CI engines > > > have no concept of packages, DSC, FDF, INFs, > firmware, > > etc. > > > > > > Okay, that's great. Of course we do also have lots of > code running on > > the CI server at work, not the client, that does > things like packaging > > etc., and this proposal will include server-side code > too. > > > > Also, I don't think there is anything that'll be as > nicely integrated > > as this, so I'm happy with it. > > > > > > -- > > Rebecca Cran > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41289): https://edk2.groups.io/g/devel/message/41289 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Yes the plan would be to support both CI and local builds. There is actually more features related to support platform builds so I think it would be better to keep ci out of the name. The reason why Tool-Env was suggested is the modules can be used to run anything within the python environment not just builds. We have a git submodule update tool, external dependency management tool (package mgmt/binary files), platform build tool, and CI build tool. Look at https://github.com/microsoft/mu_pip_environment and https://github.com/microsoft/mu_pip_build to get an idea of the content proposed. Thanks Sean -Original Message- From: Kinney, Michael D Sent: Wednesday, May 22, 2019 7:39 PM To: devel@edk2.groups.io; rebe...@bluestop.org; Sean Brogan Subject: RE: [edk2-devel] RFC for Edk2-ToolEnv Hi Sean, Does the PIP module here support both local platform builds and CI builds? I am looking at the name of the repo and trying to align with the edk2-tools-library repo name so it is obvious the two repos are related. Maybe focus on the CI part for the name and we reuse the CI features to simplify local builds. edk2-tools-ci Finalizing the name is the only open I am aware of. Thanks, Mike > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > rebe...@bluestop.org > Sent: Tuesday, May 14, 2019 4:34 PM > To: Sean ; > devel@edk2.groups.io > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv > > On 2019-05-14 17:23, sean.brogan via groups.io wrote: > > Take a look at the proposed content and how it is > used. We even have > > examples of calling from DevOps and i don't think > Jenkins would be any > > different. I don't think we are trying to duplicate CI > > functionality. We are providing the "last mile" so > that those CI > > engines can run EDK specific tests and tools. Standard > CI engines > > have no concept of packages, DSC, FDF, INFs, firmware, > etc. > > > Okay, that's great. Of course we do also have lots of code running on > the CI server at work, not the client, that does things like packaging > etc., and this proposal will include server-side code too. > > Also, I don't think there is anything that'll be as nicely integrated > as this, so I'm happy with it. > > > -- > Rebecca Cran > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41270): https://edk2.groups.io/g/devel/message/41270 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Hi Sean, Does the PIP module here support both local platform builds and CI builds? I am looking at the name of the repo and trying to align with the edk2-tools-library repo name so it is obvious the two repos are related. Maybe focus on the CI part for the name and we reuse the CI features to simplify local builds. edk2-tools-ci Finalizing the name is the only open I am aware of. Thanks, Mike > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] > On Behalf Of rebe...@bluestop.org > Sent: Tuesday, May 14, 2019 4:34 PM > To: Sean ; > devel@edk2.groups.io > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv > > On 2019-05-14 17:23, sean.brogan via groups.io wrote: > > Take a look at the proposed content and how it is > used. We even have > > examples of calling from DevOps and i don't think > Jenkins would be any > > different. I don't think we are trying to duplicate CI > > functionality. We are providing the "last mile" so > that those CI > > engines can run EDK specific tests and tools. Standard > CI engines > > have no concept of packages, DSC, FDF, INFs, firmware, > etc. > > > Okay, that's great. Of course we do also have lots of > code running on > the CI server at work, not the client, that does things > like packaging > etc., and this proposal will include server-side code > too. > > Also, I don't think there is anything that'll be as > nicely integrated as > this, so I'm happy with it. > > > -- > Rebecca Cran > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41262): https://edk2.groups.io/g/devel/message/41262 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
On 2019-05-14 17:23, sean.brogan via groups.io wrote: > Take a look at the proposed content and how it is used. We even have > examples of calling from DevOps and i don't think Jenkins would be any > different. I don't think we are trying to duplicate CI > functionality. We are providing the "last mile" so that those CI > engines can run EDK specific tests and tools. Standard CI engines > have no concept of packages, DSC, FDF, INFs, firmware, etc. Okay, that's great. Of course we do also have lots of code running on the CI server at work, not the client, that does things like packaging etc., and this proposal will include server-side code too. Also, I don't think there is anything that'll be as nicely integrated as this, so I'm happy with it. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40618): https://edk2.groups.io/g/devel/message/40618 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Take a look at the proposed content and how it is used. We even have examples of calling from DevOps and i don't think Jenkins would be any different. I don't think we are trying to duplicate CI functionality. We are providing the "last mile" so that those CI engines can run EDK specific tests and tools. Standard CI engines have no concept of packages, DSC, FDF, INFs, firmware, etc. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40617): https://edk2.groups.io/g/devel/message/40617 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
On 2019-05-14 01:37, Sean via Groups.Io wrote: > > If you know of anything I am interested as I don't like building and > supporting something unnecessary. > > This tooling isn't trying to reinvent anything but is really focused > on providing reusable/sharable functionality that can then be pieced > together by a platform to produce the required output. Today in edk2 > you see shell script files (bash/bat) and a lot of redefinition of > variables and assumptions. This is made much worse in complex closed > src code bases, complicated pre and post build requirements, and even > then managing the path and locations to tools and scripts is a fragile > mess. In practice this environment has made our build process much > more reliable, lower cost to maintain, and immune to necessary churn > at all levels of the code tree. It also has allowed our products to > get significant code reuse so we lower the cost of ongoing maintenance > and new feature introduction. > > Looking forward to gathering more input from the community as we all > don't need to build similar things. It sounds like a lot of the functionality _should_ already exist: for example I know it's not cross-platform, but MSBuild has various logging features, while I know Jenkins (unfortunately I've not worked with Azure yet) has lots of plugins for CI and running tests: at my work we have a relatively small python script that submits a "smoke" job to Jenkins and collects the results for pre-commit testing, while the same instance also checks for new changesets in the main repo and runs CI builds against them. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40616): https://edk2.groups.io/g/devel/message/40616 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
Rebecca, If you know of anything I am interested as I don't like building and supporting something unnecessary. This tooling isn't trying to reinvent anything but is really focused on providing reusable/sharable functionality that can then be pieced together by a platform to produce the required output. Today in edk2 you see shell script files (bash/bat) and a lot of redefinition of variables and assumptions. This is made much worse in complex closed src code bases, complicated pre and post build requirements, and even then managing the path and locations to tools and scripts is a fragile mess. In practice this environment has made our build process much more reliable, lower cost to maintain, and immune to necessary churn at all levels of the code tree. It also has allowed our products to get significant code reuse so we lower the cost of ongoing maintenance and new feature introduction. Looking forward to gathering more input from the community as we all don't need to build similar things. Thanks Sean -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40582): https://edk2.groups.io/g/devel/message/40582 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] RFC for Edk2-ToolEnv
On 2019-05-13 20:55, Sean via Groups.Io wrote: > > RFC Edk2-ToolEnv creation > > > > Create a new tianocore owned repository to host python code to support > an extensible, pluggable, rich environment. This environment has > command line interfaces to support building a product, building CI, > running tests, and downloading dependencies. This environment also > provides the building blocks for developers to write their own tools > to launch in the environment and leverage the capabilities provided by > the environment. The unique capabilities provided help support > building products with multiple repositories and having each > repository contribute/plugin to the build process in a scalable way. > The environment will scan the files in the code tree (multiple repos) > and discover plugins, dependencies, path adjustments, environment > variable settings, etc. This provides easy methods for common repos > to share build tools/steps. > Is there not an existing framework that could be used instead of creating something new? -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40570): https://edk2.groups.io/g/devel/message/40570 Mute This Topic: https://groups.io/mt/31614611/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] RFC for Edk2-ToolEnv
RFC Edk2-ToolEnv creation Create a new tianocore owned repository to host python code to support an extensible, pluggable, rich environment. This environment has command line interfaces to support building a product, building CI, running tests, and downloading dependencies. This environment also provides the building blocks for developers to write their own tools to launch in the environment and leverage the capabilities provided by the environment. The unique capabilities provided help support building products with multiple repositories and having each repository contribute/plugin to the build process in a scalable way. The environment will scan the files in the code tree (multiple repos) and discover plugins, dependencies, path adjustments, environment variable settings, etc. This provides easy methods for common repos to share build tools/steps. Inclusion of this package and dependency management should be managed using Pip/Pypi. To start this is a supplemental package and is not required to be used for edk2 builds. More details below but much of this content is coming from combining two existing repos * https://github.com/microsoft/mu_pip_environment ( https://github.com/microsoft/mu_pip_environment ) * https://github.com/microsoft/mu_pip_build ( https://github.com/microsoft/mu_pip_build ) This RFC is part 2 of content from design review: https://edk2.groups.io/g/devel/files/Designs/2019/0418/2019-04-18%20Microsoft%20-%20Build%20Tools%20-%20Design%20Review%20.pdf ( https://edk2.groups.io/g/devel/files/Designs/2019/0418/2019-04-18%20Microsoft%20-%20Build%20Tools%20-%20Design%20Review%20.pdf ) Examples of content here * CI build support - https://github.com/microsoft/mu_pip_build/blob/master/MuBuild/MuBuild.py ( https://github.com/microsoft/mu_pip_build/blob/master/MuBuild/MuBuild.py ) * Binary Dependency resolution * Nuget - https://github.com/microsoft/mu_pip_environment/blob/master/MuEnvironment/ExternalDependencies.py ( https://github.com/microsoft/mu_pip_environment/blob/master/MuEnvironment/ExternalDependencies.py ) * GitHub Releases - WIP * URL dependency - WIP * Logging * File logger * Markdown logger * In Memory loggers - For tool parsing * Console loggers with colors * PlugIns * Support pre/post build steps * Support supplying functions * UefiBuild - A wrapper around Edk2 build process that a Platform would subclass. https://github.com/microsoft/mu_pip_environment/blob/master/MuEnvironment/UefiBuild.py ( https://github.com/microsoft/mu_pip_environment/blob/master/MuEnvironment/UefiBuild.py ) * VarDict and ShellEnvironment - Manage the shell environment and all the name/value pairs used in the build process (including pre/post). * Omnicache - Support a super cache of git repos to speed up creating and updating multiple work spaces and minimizing filesystem impact Maintainers * Sean Brogan * Bret Barkelew * Placeholder for existing maintainer from the basetools License * BSD + Patent (edk2 aligned) Contribution process and issue tracking * Follow Github PR process for contributions and issue tracking * Contributor forks repo in github * Contributor creates branch for work * Contributor updates release notes to indicate change (if necessary) * Contributor submits PR to master branch of tianocore/Edk2-ToolEnv repo * Review feedback is given in PR * Python Tests are run on the repo (new contributions need unit tests) * Python Style (flake8) must pass * All review feedback must be completed, maintainers approved, and tests run successfully before PR is *squash merged* into master Documentation * Use Github IO documentation/wiki hosting * Example content i. https://microsoft.github.io/mu/dyn/mu_pip_environment/developing/ ( https://microsoft.github.io/mu/dyn/mu_pip_environment/developing/ ) ii. https://microsoft.github.io/mu/dyn/mu_pip_environment/publishing/ ( https://microsoft.github.io/mu/dyn/mu_pip_environment/publishing/ ) * Readme at root of repo * Example: https://github.com/Microsoft/mu_pip_environment ( https://github.com/Microsoft/mu_pip_environment ) CI Builds * CI build process using dev ops * Validation is done thru build process * Release publication done thru manual CI Build * Examples from Mu-Environment * Windows CI - https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=10 ( https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=10 ) * Linux CI - https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=11 ( https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=11 ) * Publishing - https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=17 ( https://dev.azure.com/projectmu/mu%20pip/_build?definitionId=17 ) Release * Release to Pypi as Edk2-ToolEnv for easy usage in product environment * Versioned follows: Aa.bb.cc.dd * AA == Major version. Changes don’t need to be backward compatible * BB == Minor version. Significant new features. Backward compatibility maintained * CC == Bug
