Add publishing of NuGet package with CLI version #167
Conversation
- Updated the README.md with a description of the two packages - Updated the azure pipeline - Corrected the help text for the MDP console application Signed-off-by: Frank Robijn <robijn@good-heavens.nl>
WalkthroughThe recent changes to the Azure Pipelines configuration enhance the build process by introducing tasks for managing build numbers and packing a NuGet package. A script for setting cloud build variables ensures accurate versioning after tests are executed. Additionally, a PowerShell task saves the build number derived from the NuGet package version, and a new task for packing the package is included. These updates streamline automation and improve the overall deployment process. Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant AzurePipelines
participant Testing
participant NuGet
Developer->>AzurePipelines: Start Build
AzurePipelines->>Testing: Run Tests
Testing-->>AzurePipelines: Return Test Results
AzurePipelines->>AzurePipelines: Update Build Number
AzurePipelines->>NuGet: Pack NuGet Package
NuGet-->>AzurePipelines: Package Created
AzurePipelines-->>Developer: Build Complete
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (3)
MetadataProcessor.Console/Program.csis excluded by none and included by noneMetadataProcessor.Console/package.nuspecis excluded by none and included by noneREADME.mdis excluded by!**/*.mdand included by none
Files selected for processing (1)
- azure-pipelines.yml (2 hunks)
Additional context used
yamllint
azure-pipelines.yml
[error] 216-216: trailing spaces
(trailing-spaces)
[warning] 221-221: wrong indentation: expected 6 but found 8
(indentation)
[error] 228-228: trailing spaces
(trailing-spaces)
Signed-off-by: Frank Robijn <robijn@good-heavens.nl>
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- azure-pipelines.yml (2 hunks)
Additional context used
yamllint
azure-pipelines.yml
[error] 216-216: trailing spaces
(trailing-spaces)
[warning] 221-221: wrong indentation: expected 6 but found 8
(indentation)
Additional comments not posted (3)
azure-pipelines.yml (3)
216-216: Remove trailing spaces.Line 216 contains trailing spaces, which should be removed for cleaner code.
Tools
yamllint
[error] 216-216: trailing spaces
(trailing-spaces)
221-221: Correct indentation.The indentation on line 221 is incorrect. It should be adjusted to align with the expected YAML structure.
Tools
yamllint
[warning] 221-221: wrong indentation: expected 6 but found 8
(indentation)
228-228: Remove trailing spaces.Line 228 contains trailing spaces, which should be removed for cleaner code.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- azure-pipelines.yml (2 hunks)
Additional context used
yamllint
azure-pipelines.yml
[error] 216-216: trailing spaces
(trailing-spaces)
Additional comments not posted (14)
azure-pipelines.yml (14)
213-213: LGTM!The script command to set cloud build variables is correctly implemented.
214-214: LGTM!The condition
succeeded()is correctly used to ensure the script runs only if previous tasks succeeded.
215-215: LGTM!The display name "Set build number" is clear and descriptive.
217-217: LGTM!The PowerShell task is correctly defined.
218-218: LGTM!The condition
succeeded()is correctly used to ensure the PowerShell task runs only if previous tasks succeeded.
219-219: LGTM!The display name "Save cloud build number" is clear and descriptive.
220-220: LGTM!The inputs section is correctly structured.
222-222: LGTM!The script to update the build number is correctly implemented.
223-223: LGTM!The blank line is appropriately placed for readability.
224-224: LGTM!The NuGetCommand task is correctly defined.
225-225: LGTM!The condition
succeeded()is correctly used to ensure the NuGetCommand task runs only if previous tasks succeeded.
226-226: LGTM!The display name "Pack NuGet with MetadataProcessor Console" is clear and descriptive.
227-227: LGTM!The inputs section is correctly structured.
229-229: LGTM!The arguments for the NuGetCommand task are correctly specified.
josesimoes
changed the title
josesimoes
changed the title
|
@frobijn thank you again for your contribution! 🙏😄 .NET nanoFramework is all about community involvement, and no contribution is too small. Please edit it and add an entry with your GitHub username in the appropriate location (names are sorted alphabetically): (Feel free to adjust your name if it's not correct) |
Description
The package is named nanoFramework.Tools.MetadataProcessor.CLI to emphasize that it is intended to be an interface and not a general purpose tool. In the tags only nanoFramework is kept, as this is not a tool for the general audience.
In the README.md I've tried to describe the specific use case. I've tried to phrase the text in a way to discourage a regular user to play with this package. I've tried to describe (better?) my use case, where I have unit tests that generate code, compile the code with Roslyn, make a .pe assembly, use nanoclr --loadassemblies and use the output to assert whether a test is successful. This is probably a very niche application, for users who meddle with source generators.
For this application the content of the package needs to end up in the output (bin) directory of the project that uses the package. The code in the project will use something as Cli.Wrap (nanoFramework.Tools.MetadataProcessor.exe) to convert a *.dll to *.pe file. Hence the package will put the MDP-files in the content directory and not the lib or tools directory.
Unfortunately the way package managers handle content files differs.
The nuspec supports both package managers, which means that each file is in two locations in the package. This is in line with the recommendations in the description of the NuSpec format.
The azure pipeline is updated. Two steps are taken from the nuspec of the TestFramework. I understand the NuGet command but do not know if the version-related one is applicable. I've also moved a nbgv-command up the list, as I suspect the task must be run before the version is copied to the variable.
Motivation and Context
See the description for my specific use case. Earlier today I tried that and found that a feature I was using has a different implementation in nF than in .NET. Being able to test the code on a virtual device as part of a unit test very early on in the development cycle saves a lot of time. Any converter from *.dll to *.pe is fine. The MDP.exe is best suited as it already exists, is a console application so there are no problems with package dependencies and framework versions. It does more than needed, but I guess the typical user of this package is smart enough to leave those options alone.
How Has This Been Tested?
I don't know how to test the azure pipeline.
(I did not test the use of the package from the code of the project. I've done that before.)
Types of changes
Checklist:
Summary by CodeRabbit
These improvements streamline the deployment process and enhance version control in the build pipeline.