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.

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

How to provide latest released package version? #62

Open
Mattue opened this issue May 4, 2021 · 12 comments
Open

How to provide latest released package version? #62

Mattue opened this issue May 4, 2021 · 12 comments
Labels
enhancement New feature or request

Comments

@Mattue
Copy link

Mattue commented May 4, 2021

Hi.

I'm playing around with SF packages CI/CD and some of packages contains dependencies to other packages.

How to properly provide latest version in sfdx-project.json so sfdx texei:package:dependencies:install would install it correctly? For now it will install older version even if latest version is installed already.

  1. Install latest version via sfdx texei:package:dependencies:install
{
...
    "dependencies": [
        {
            "package": "PackageName",
            "versionNumber": "1.4.3.LATEST"
        }
    ]
...
}

> sfdx texei:package:dependencies:install -u myOrg -k "1:some_password"

Package dependencies found for package directory force-app
    04t3Y000001QpjJQAS : PackageName 1.4.3.LATEST
Resolving dependencies... Done.

Installing package 04t3Y000001QpjJQAS : PackageName 1.4.3.LATEST

...

  1. Downgrade version of dependent package in sfdx-project.json
{
...
    "dependencies": [
        {
            "package": "PackageName",
            "versionNumber": "1.3.3.LATEST"
        }
    ]
...
}

> sfdx texei:package:dependencies:install -u myOrg -k "1:some_password"

Package dependencies found for package directory force-app
    04t3Y0000011MwvQAE : PackageName 1.3.3.LATEST
Resolving dependencies... Done.

Installing package 04t3Y0000011MwvQAE : PackageName 1.3.3.LATEST
...

Also RELEASED keyword is not working with texei plugin is it expected?

> sfdx texei:package:dependencies:install -u myOrg -k "1:some_password"
Package dependencies found for package directory force-app
ERROR running texei:package:dependencies:install: 
PatchVersion=3 and BuildNumber=RELEASED  ORDER BY BuildNumber
                              ^
ERROR at Row:1:Column:225
Bind variables only allowed in Apex code
Resolving dependencies... done
@FabienTaillon
Copy link
Member

@Mattue sorry not sure I got your point.
Are you saying that if your sfdx-project.json file reference a version 1.3.3.LATEST it will install it even if a version 1.4.3.LATEST is already installed in the org ?

For the RELEASED keyword, I think this was just not existing when we wrote this command, so it needs to be added, I'll flag this as an enhancement.

@FabienTaillon FabienTaillon added the enhancement New feature or request label May 4, 2021
@Mattue
Copy link
Author

Mattue commented May 4, 2021

Are you saying that if your sfdx-project.json file reference a version 1.3.3.LATEST it will install it even if a version 1.4.3.LATEST is already installed in the org ?

Yes, this is correct.

@FabienTaillon
Copy link
Member

Well then I think it's working as designed, as the command is supposed to reflect what's in your dependency tree. Why not update your sfdx-project.json with the correct dependency ?

@Mattue
Copy link
Author

Mattue commented May 4, 2021

I was expecting that using LATEST or RELEASED keyword will check if any of latest dependency versions are installed. Well it does, but on build level. May be LATEST keyword can be applied on minor and major somehow - I'm just not aware. I would appreciate if you advice.

One problem that I see is that you may forgot to change dependency version in sfdx-project.json. Plugin will install the older version that may cause other packages fail or fail processes around this dependent package.

Also we have several teams that develop packages using same dependency, and forcing them to follow for latest releases may cause some head blown ups 😄

There may be more, but I came with this one yet.

@FabienTaillon
Copy link
Member

I do agree this is not ideal but that's the way Salesforce made it regarding the LATEST keyword. That's the same version that is used to build a new package from this project.

So if you don't update your sfdx-project.json, your new Unlocked Package (depending on the version listed under dependencies) would also be based on the wrong version.

If you want to have more dynamic installs between several projects, you should have a look the sfpowerscripts orchestrator which may be doing what you want.

@Mattue
Copy link
Author

Mattue commented May 4, 2021

So if you don't update your sfdx-project.json, your new Unlocked Package (depending on the version listed under dependencies) would also be based on the wrong version.

Could not agree with that. Salesforce has no restrictions on dependencies when installing using sfdx force:package:install or via UI. It's just installing if dependent package is installed (again, never tried with major version difference)

May be plugin can have something like --package parameter that will just check if dependent package installed, but not installing version that provided in sfdx-project.json

I will review sfpowerscripts orchestrator, thanks for advice. But I was hoping that when I use plugin, my headache is taken by this plugin and everything is working with one button. Don't really want to implement complicated logic, in this case plugin is no use for me.

@FabienTaillon
Copy link
Member

Could not agree with that. Salesforce has no restrictions on dependencies when installing using sfdx force:package:install or via UI. It's just installing if dependent package is installed (again, never tried with major version difference)

I was talking about sfdx force:package:version:create and not sfdx force:package:install.
If you were to create a package version for a project depending on 1.3.3.LATEST it would use the latest 1.3.3 version, and not pick the 1.4.3 version even if it exists. What I was saying is that there is no way to use something like 1.3.LATEST, which would be what you want.

What you are basically requesting is either to use 1.3.LATEST (not something Salesforce provides), or saying "I wrote 1.3.3 but I don't want why I wrote, I want 1.4.3".

I agree that's not convenient for your use case but we are just following what Salesforce provides regarding the LATEST keyword and the way to write dependencies in the sfdx-project.json file.

@Mattue
Copy link
Author

Mattue commented May 5, 2021

Didn't understand this one

If you were to create a package version for a project depending on 1.3.3.LATEST it would use the latest 1.3.3 version, and not pick the 1.4.3 version even if it exists.

We can't install several versions of packages in Salesforce, only one. You saying that if in sfdx-package.json provided dependency version 1.3.3.LATEST Salesforce will use code from version provided even if newer version is installed? Sounds strange for me. Let me do some experiments.

What you are basically requesting is either to use 1.3.LATEST (not something Salesforce provides), or saying "I wrote 1.3.3 but I don't want why I wrote, I want 1.4.3".

This is not clear understanding. I want to use latest available version, or latest available version starting from major version 1. And just not think about it when creating my packages. In case when I'm providing strict version number like 1.2.3, I'm expecting error throw if this version is not installed in org.

@FabienTaillon
Copy link
Member

I understand, you want to use the latest available version. What I say, is that there is no way to specify this in in the sfdx-project.json.
If you look at the doc, all the keywords like LATEST are only available at the build level:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_config_keywords.htm

Then you can still manually install whatever version you want, but when we talk about sfdx-project.json, you'll have to specify a given version, beside the build number.

@Mattue
Copy link
Author

Mattue commented May 5, 2021

That is understandable and I'm not arguing over standard Salesforce functionality and features. But should plugins expand and simplify standard feature usage?

@FabienTaillon
Copy link
Member

It may, I guess that's what sfpowerscripts orchestrator is doing.
But this specific command is just about installing all packages dependencies just as described in your sfdx-project.json.

Why ? Well let's say that you have a package A, and a package B depending on it.
Let's say package A version 1.0.0 has a class named MyClass, and package B relies on it in its own code.
Package A may be updated to version 1.1.0 with maybe some refactoring, where MyClass would be deleted. Then if the command was automatically taking the latest release (1.1.0) instead of the one listed under dependencies (1.0.0), then your build would be broken until you fix the use of the missing class.

But your new version 1.1.0 may still be under development and not ready for prime time, so why use it absolutely ? Maybe you're just testing stuff, and until it's promoted you can still change your mind and reverse some changes. If you always take the latest version instead of the one listed, you would have no way to install the previous version you want, whereas the other way round you still can update the dependency version in your sfdx-project.json file.

Let me be honest, I wish there would be a way to use something like 1.LATEST, but unfortunately there is not.
The goal of this command is just, whether you have 1 or 10 dependencies in your file, you don't have to run 10 times the force:package:install command, but only one that will dynamically parse your sfdx-project.json, get the number of packages and package ids and install them.

So I do understand that there is a need for what you ask, but I think it's outside of this command's scope.
Still, the code is open source so you can create your own command from it if sfpowerscripts orchestrator isn't also doing what you want.

I'll keep this issue open because still, RELEASED keyword should work, thanks for letting me know.

@Mattue
Copy link
Author

Mattue commented May 5, 2021

Sure, got your point. Sad to read that, but thanks.

Thank you for your communication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants