Closed sauloefo closed 6 months ago
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.
hey @sauloefo, we're currently working on the beta versions of the packaging
commands and would love to fix it there. Could you please try using the force:package:beta:version:create
command and see if this bug is still present?
@sauloefo all the beta has been live for awhile. Any luck? Is this still reproducible?
This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.
Hi @mshanemc I am facing the same issue, actually we have CI-CD pipelines where we create workspace-server then install latest version of SFDX and then create new unlocked package version.
I also tried sfdx package version create ...
but still same. It is crucial for us, and we want to track old versions because we need to follow SOX compliance.
HI @mshanemc do we have an update on this, it is getting critical for us as we are losing the tracking system, as we track all changes according to version
@honeyverma - if this is a critical issue I would definitely go through the support channels so a case can be created for the packaging team, who is the best team to address this. Since there is no SLA with GitHub issues I'll do my best to at least reproduce this and if something stands out I'll try to get a fix in.
@honeyverma - I reproduced the bug with CLI v7.197.8 and packaging plugin v1.16.5. I highly recommend opening a support case with the packaging team about this since that is how they intake issues.
We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.
HI @shetzel thanks for the inputs and confirmation, I am going to open a ticket and refer this issue link as well.
Case number: 44544046
Apologies for being late to this thread but what @sauloefo describes is exactly what I would expect the behavior to be.
If you build a package version with a branch designation of NULL, you will get package-name@0.0.0-1
and a corresponding record id (i.e., '04t000000000001AAA').
If you then update package version '04t000000000001AAA' to now have a branch, then the DEV HUB is aware of this change; not the local sfdx-project.json.
If you have not updated the alias in the sfdx-project.json
, the alias is still package-name@0.0.0-1
.
When you create a new package version with a branch designation of NULL, the DEV HUB will pick the next available version number for that MAJOR.MINOR.PATCH level specified in the sfdx-project.json
...on the branch designated in the command -- which is NULL. Since there is currently no package version on this branch designation of NULL where the MAJOR.MINOR.PATCH is "0.0.0", then the DEV HUB will create a package version and give it the version number which is "one build number higher than the previous version number with the same branch designation." Since, in this case, there are currently no package version builds on this MAJOR.MINOR.PATCH version on the branch designation of NULL, then the DEV HUB would assign the "build number" for this new package version to be "1"... thus the new package version number is "0.0.0-1" with Branch designation of NULL.
The CLI is updating the sfdx-project.json
with the new package version number. It will work with the existing packageAliases
in the sfdx-project.json
. Since it treats that JSON object much like a "set", when it adds the new package version alias, it would -- in this scenario -- overwrite the original value.
The workaround that I would suggest is that when you manually add a branch designation to an existing package version in the DEV HUB, manually update the packageAlias of that package version to include the branch designation. In the example above, I would suggest renaming the packageAlias to be "package-name@0.0.0-1-any-text-here"
I would say that this very much is "working as designed".
Please let me know if you have questions.
cc: @WillieRuemmele , @mshanemc, @shetzel, and @honeyverma
Link to known issue: https://issues.salesforce.com/issue/a028c00000ixJuFAAU/~ W-13185383
The packaging team has determined that this behavior is working as designed. Packaging documentation will be updated to clarify this.
Summary
sfdx force:package:version:create
doesn't create the version using the next build number if the last created package version has the branch changed by the commandsfdx force:package:version:update
Steps To Reproduce:
sfdx-project.json
file, set versionNumber of the package to0.0.0.NEXT
;sfdx force:package:version:create -p id-of-the-package
;id-of-created-version
;sfdx force:package:version:update -p id-of-created-version --branch any-text-here
;sfdx force:package:version:create -p id-of-the-package
;Expected result
In
sfdx-project.json
,packageAliases
should looks like:In
sfdx force:package:version:list -p id-of-the-package
result should looks likeActual result
In
sfdx-project.json
,packageAliases
it looks like:In
sfdx force:package:version:list -p id-of-the-package
result should looks likeSystem Information
Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)
If you are using
sfdx
sfdx version --verbose --json
If you are using
sf
sf version --verbose --json
Paste the output here
Additional information
Feel free to attach a screenshot.