search

majkinetor / au

Chocolatey Automatic Package Updater Module
GNU General Public License v2.0
227 stars 71 forks source link

Forced Packages not working? #241

Closed DarwinJS closed 3 years ago

DarwinJS commented 3 years ago

I might be misunderstanding the requirements - but the docs here: https://github.com/majkinetor/au#force-update note that using force should create chocolatey fix versions with the date. However, as you can see in the screenshot, I am successfully setting the parameter - but it ignores my wishes :(

I tried with and without NoCheckChocoVersion.

AU Version is 2020.11.21

image

image

DarwinJS commented 3 years ago

Hmmm - so I also tried forcing au_version like the docs say and it bombed out. (did it at a global level since all packages are the same version). I also tried au_version in update for each package and received the same error because the new version is not overriden.

image

DarwinJS commented 3 years ago

I see that au_version is resused in this line: . "$Env:TEMP/au/scripts/Install-AU.ps1" $Env:au_version so if I set it at the CI level - it messes up right there.

Having a hard time getting set_fix_version to run.

majkinetor commented 3 years ago

You are not using the feature right.

  1. To force the single package, you either Update-Package -Force or set env var au_Force to true.
  2. To force all packages with updateall, you force within options.
  3. You can also force individual packages like this
DarwinJS commented 3 years ago

Ok I tried the third option by setting "FORCED" to two packages, but it still does not add the fix version? (please see below)

image

DarwinJS commented 3 years ago

Does this line: https://github.com/majkinetor/au-packages/blob/06f52d122b6a665171202b35bead07ba20ca99fa/update_all.ps1#L9

Need to be Force = $Env:au_force -eq 'true' ?

majkinetor commented 3 years ago

Mhm... not sure until I see the full code. This feature is used non-stop all around.

Does your updateall script has this line ?

Do you have repository with this setup (I looked at your GitLab repo but I don't see AU stuff). The repo should be created via au-packages template in general for it to just work as expected.

You may temporarily try setting the explicit version yourself until the problem is found, eg: pwsh:7.1.3.20210315

I just tried once for test and it works as expected.

majkinetor commented 3 years ago

Does this line: https://github.com/majkinetor/au-packages/blob/06f52d122b6a665171202b35bead07ba20ca99fa/update_all.ps1#L9

Need to be Force = $Env:au_force -eq 'true' ?

THAT force is used to force ALL packages, not just some of them. You can set it up that way, but I wouldn't do so - $Env:au_force is what you should set when working with single package. If you accidentally leave it on and in same pwsh session you latter call updateall you can accidentally push ALL packages...

That option is mainly used in combination with Push: $false in order to test packages

DarwinJS commented 3 years ago

OK I think I figured out how I got myself in a twist. I ran an update from 7.1.2 to 7.1.3, but the push to git failed.

Now when I force it, the source is still 7.1.2 and 7.1.3. is up on chocolatey - so it does not know to do the fix version and then it runs into the package clash and still does not update source (the whole reason I'm pushing a fix version in the first place).

majkinetor commented 3 years ago

Ah yeah, that happens, if there is newer version, force can't be used, naturally. Just update version on git since its authority for AU.

DarwinJS commented 3 years ago

Thanks for your help. I now have your automated packages framework running from a GitLab repository on a GitLab runner. It works up through pushing back to the repository - but I still have to see about configuring testing.

It is here: https://gitlab.com/guided-explorations/microsoft/chocolatey/powershell-core

Another challenge is the powershell-preview package is published on the same GitHub project, but I've been using a separate package id (because it goes to another folder and then folks can update both without having two independent ones on the same feed.

Would streams work to publish to separate package ids? Maybe I should just reunify them on the same package id?

FYI GitLab is planning NuGet.Core 2.x compatibility - once that is in the product, the internal NuGet feed in each project can be used to test packages - or if you use the virtual feed at a higher level group, your package repository tree can be your chocolatey end point.

majkinetor commented 3 years ago

Would streams work to publish to separate package ids? Maybe I should just reunify them on the same package id?

Yeah, just change PackageName within stream.

once that is in the product, the internal NuGet feed in each project can be used to test packages

Nice. This is good reason to use GL with AU so you can have working packages when gallery admins wont allow them due to copyright or other reasons. I guess having runner ready template should be done to support this beside AV.