Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Promote Package does not fail when it should #53

Open
alesremta-ext43767 opened this issue Apr 25, 2024 · 9 comments · May be fixed by #61
Open

Promote Package does not fail when it should #53

alesremta-ext43767 opened this issue Apr 25, 2024 · 9 comments · May be fixed by #61
Assignees
@dieffrei
Labels
enhancement New feature or request

Comments

@alesremta-ext43767
Copy link

Describe the bug
Promoting a package which is being built on a MAJOR.MINOR.PATCH combination which has previously been promoted DOES NOT FAIL, instead it prints: "VERSION_ID is already promoted". This is not true, the version number being built is NOT promoted, it is a previous build of the same package.

This hides the fact that a version bump was not performed and only manifests itself when attempting to release to PROD.

packages/core/src/package/promote/PromoteUnlockedPackageImpl.ts

try {
    result = await packageVersion.promote();
    result.id = packageVersionData.SubscriberPackageVersionId;
} catch (e) {
    if (e.message.includes('previously released')) {
        SFPLogger.log(`Package ${this.package_version_id} is already promoted, Ignoring`);
    } else throw e;
}

To Reproduce

  • Build and Promote a package
  • Do not add any changes in version numbers
  • Build and Promote a package again

Expected behavior
Error that package cannot be promoted, becuase another build of the same MAJOR.MINOR.PATCH has already been promoted
CLI Error: "You already promoted a package version with this major.minor.patch version number. For a given major.minor.patch number, you can promote only one version."

Actual behaviour
Package 04tXXXXXXXX is already promoted*** Ignoring

Platform Details (please complete the following information):
Tested with older version: sfp -- The DX@Scale CLI -Version:25.5.3 -Release:December 23
But checked code in new SFP repository and it is still the same.

  • OS:
  • Version [e.g. CLI Version eg: 1.6.6]
  • Salesforce CLI(sfdx cli) Version:
  • CI Platform: GitHub Actions

Additional context
Add any other context about the problem here.
@dieffrei dieffrei added the enhancement New feature or request label May 4, 2024
@dieffrei dieffrei self-assigned this May 4, 2024
@dieffrei dieffrei removed the analysis label May 5, 2024
@dieffrei
Copy link
Collaborator

I agree, I felt that pain many times. I will take a look @alesremta-ext43767 what we can do

@azlam-abdulsalam azlam-abdulsalam modified the milestone: June 24 May 21, 2024
@azlam-abdulsalam azlam-abdulsalam removed the enhancement New feature or request label May 21, 2024
@azlam-abdulsalam
Copy link

We need to account for retries while using release command. An inability to promote should not hinder one to retry a release. I think the best option is to do a dry run and check for issues upfront. For eg in sfops,

image

@alesremta-ext43767
Copy link
Author

alesremta-ext43767 commented May 24, 2024 •
edited
Loading

Hi @azlam-abdulsalam I think it should be fine so long as there is a distinction between a) promoting already promoted version again (SF CLI will just give a "success" response) and b) promoting a different build of an already promoted major.minor.path combo (SF CLI will throw an error)

If we create a new release, don't bump a version number, but do another build. Then that package CANNOT be moved to PROD

@dieffrei dieffrei added the enhancement New feature or request label May 26, 2024
@odaybov-cen56981
Copy link

hi @azlam-abdulsalam I'm also involved to this topic. just i vote for the ver b) promoting a different build of an already promoted major.minor.path combo (SF CLI will throw an error)

  • thx.

@dieffrei dieffrei linked a pull request May 26, 2024 that will close this issue
53 - Package promotion enhancement #61
Draft
5 tasks
@dieffrei
Copy link
Collaborator

dieffrei commented May 26, 2024 •
edited
Loading

I agree with @azlam-abdulsalam there are some edge cases that it could be tricky.
However, we can have a flag for that "--fail-if-promoted", then we can keep the existing behavior and keep backward compatibility.
@odaybov-cen56981 @alesremta-ext43767 @azlam-abdulsalam

@azlam-abdulsalam
Copy link

The need is mainly driven by the 'promoteBeforeDeployment' attribute in release defn, where most orgs just promote it before deploying to prod. I think @dieffrei's solution could be perfect, we could add an additional attribute or flag

@alesremta-ext43767 is this the promote command or release command?

@alesremta-ext43767
Copy link
Author

We are using the "promote command". But to be honest, for me this is much more low level. Whatever you do, promote or release, ultimately does this:
sf package version promote --package xxxxx --target-devhub-org xxxx
And my issues is that when this command fails, the SFP command must fail. Because it means that the promotion could not be done and therefore the package cannot be installed in PROD. Right now this is not the case. SFP catches all "errors" and assumes this was due to the fact that the given Package Version is already promoted. But that is not always the case. Sometimes it's not the specific Package Version that was already promoted but rather a different Package Version with the same MAJOR.MINOR.PATCH combo (just different build, from previous release definition perhaps) and then this cannot be ignored.

@alesremta-ext43767
Copy link
Author

@dieffrei @azlam-abdulsalam I would say it's a lot more important for the Promote command. For release, if this issue is in place, you're going to fail right after (attempting to install). But if your process is to prepare artefacts ahead of time to do a just in time release (perhaps in a short prod maintenance window) you want to be as close to 100% sure it'll install successfully as you can. So you would promote ahead of time and rely in the fact that this package is promoted successfully.

@dieffrei
Copy link
Collaborator

@alesremta-ext43767 In terms of effort, the release command uses the promote command.
We will change both anyway.
Probably, I will add the flag for both commands

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dieffrei dieffrei

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

53 - Package promotion enhancement flxbl-io/sfp
4 participants
@dieffrei @azlam-abdulsalam @alesremta-ext43767 @odaybov-cen56981