rc1.0: Upload manifest file for release branch #21152
Conversation
This PR uploads dev manifest files to azure blob. The following bunch of steps are added to the pipeline: 1. Run `flub release report -g client -o <path_generate_manifest_files> --baseFileName foo` - This command generates the manifest file as per the current state of the repository. It names the manifest files as `foo.full.json, foo.caret.json, foo.simple.json, foo.tilde.json` 2. Run `flub release report-unreleased -V <dev_version> -c <path_caret_manifest> -s <path_simple_manifest> -o <output_directory>` - This command accepts the dev version that is set in the pipeline. Later, it updates the generated manifest files in the pipeline pointing the values to the dev version. The manifest files undergo renaming in two formats: one based on the date and the other on the build number. 3. Later, after uploading the dev manifest files to azure blob, the manifest files are deleted to avoid failures at the step `Check for extraneous modified files`. Pipeline Run: https://dev.azure.com/fluidframework/internal/_build/results?buildId=259575&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76 This is how the upload folder looks:  [AB#7884](https://dev.azure.com/fluidframework/internal/_workitems/edit/7884)
The manifest file is uploaded by date and build number for main branch. This change extends the functionality for release branches too. For release branches, the manifest file is uploaded based on the build number, rather than the date. This approach prevents it from overriding the one uploaded from the main branch. Once this PR is merged in main, I can port the change to release branches.
| - task: PublishPipelineArtifact@1 | ||
| displayName: Publish release reports | ||
| continueOnError: true | ||
| inputs: | ||
| targetPath: ${{ parameters.buildDirectory }}/upload_release_reports | ||
| artifactName: 'release_reports' |
There was a problem hiding this comment.
rc1 was before we started using 1ES pipelines so this should be ok in this port, compared to the rc2 and rc3 ones.
|
A test is failing for this PR, unlike the others. |
|
My suggestion would be to comment that test. We had the same issue when porting another change to the rc branches; some of build-tools' "unit tests" assume that some things haven't happened in the real world (like having published rc3) so when we run them again after that has happened, they will always fail. And since we won't be releasing build-tools from this release branch, it should be ok to not have the test. |
sonalideshpandemsft
force-pushed
the
upload-manifest-rc.1.0
branch
from
8a00cac
to
4530ed2
Compare
sonalideshpandemsft
merged commit 02fd923
into
release/client/2.0.0-rc.1.0
@alexvy86 @sonalideshpandemsft I was too slow for this PR, but what I would have recommended is using a newer version of build-tools in the pipeline. That's why we support running the pipeline using the in-repo version and a version installed from npm - so we can run pipelines on older or newer build-tools versions and don't have to maintain build-tools code on a release branch. If there's a bug in the new commands, the fix will have to be ported to each pipeline where the code lives. Better to be able to bump versions. |
Cherry-pick #21143 and #20722