FR: Ability to pass in an archive flag to do some pattern matching

[NikRimington]

Twitter thread from Matt Brailsford below describing both scenario and how it could work:

Source: https://twitter.com/mattbrailsford/status/1263011754075979776

Niice! This should make deploying Umbraco packages so much easier. When a package is published, is the current package file on our archived? And what about if the package isn’t the “current” pkg ? Eg Vendr has a main pkg + payment provider pkgs listed.

The core pkg is always “current”. If I published a payment provider pkg would the existing one be archived? If not, maybe an -a flag can be passed with a pattern to match and archive any matches?

[mattbrailsford]

I think the -a flag might be the way to go, but it's just working out the best approach for this. From a Vendr perspective, in our package list we have Vendr.x.x.x.zip for the core package and Vendr.PaymentProviders.ProviderName.x.x.x.zip for each of the providers so it's a question of what pattern matching would be required.

Simplest could be just a wildcard approach such as Vendr.*.zip but this could be a problem in a setup like mine where all my packages begin Vendr. This being said, for the core release, I could push without an archive flag and because this package is flagged as "Current" you could say any "current" flagged push should auto archive the current "current" pkg. Then for the payment providers which aren't "current" I could use an archive flag like -a Vendr.PaymentProviders.ProviderName.*.zip which would work.

Other option could be a regex, but not sure if that is overkill?

[jmayntzhusen]

Have considered this, until I realized what we are doing with Forms, where the release: UmbracoForms.Package.{version}.zip & UmbracoForms.Files.{version}.zip, and then we have latest v4, latest v7 and latest v8 ones as unarchived..

Will be super tough to do this in a good way, which is what lead me to suggest an "auto-archiving" feature on Our instead, where it will just hide the ones that aren't the latest compatible version with a specific Umbraco version: https://github.com/umbraco/Umbraco.Packages/issues/69

[mattbrailsford]

Assuming each Umbraco forms package is being deployed individually, couldn't an archive flag be -a UmbracoForms.Package.4.*.zip and each major release could include it's major number as part of the pattern?

[mattbrailsford]

Hey folks, just wondering if there has been any updates on this? Would love to start integrating UmbPack in my build process, but I think this and one other are holding me back atm.

[jmayntzhusen]

I think it would be a good idea to get this done, is that something you would be up for helping with @mattbrailsford ? 🙂

In this line: https://github.com/umbraco/UmbPack/blob/dev/src/Verbs/PushCommand.cs#L68 You can see that we actually grab a list of package files that are currently related to the package, they are returned as json, something like this:

  {
    "Id": 1477,
    "Name": "Cultiv.EnvironmentIndicator_1.0.0.zip",
    "Path": "/media/wiki/10969/634219856665830000_CultivEnvironmentIndicator_100.zip",
    "FileType": "package",
    "NodeVersion": "432ba1dd-81a4-43b5-b493-16943add56c0",
    "CreatedBy": 4576,
    "RemovedBy": 0,
    "NodeId": 10969,
    "CreateDate": "2010-10-06T18:14:26.59",
    "Current": true,
    "Downloads": 634,
    "Archived": true,
    "Verified": false,
    "SupportsMediumTrust": false,
    "Versions": [],
    "Version": {
      "Version": "v840",
      "Name": "Version 8.4.x",
      "Description": null
    },
    "MinimumVersionStrict": null,
    "DotNetVersion": null
  }

Would be great if you or anyone else could help out with the UmbPack parts of pattern matching the archive flags to the returned names in this json list, and then pass along the ids of each package file when pushing, then on Our we need something to archive them similar to https://github.com/umbraco/OurUmbraco/blob/master/OurUmbraco/Our/Controllers/ProjectController.cs#L292, but in the UmbPack controller: https://github.com/umbraco/OurUmbraco/blob/master/OurUmbraco/Project/Api/ProjectUploadController.cs#L97

As mentioned in another issue, the Our dev db is currently not available, but if someone picks up the umbpack parts I will do the Our parts 🙂

[umbrabot]

Hi @NikRimington,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[mattbrailsford]

I may try and have a play this evening. Are we going with the rule that says if the package is marked as current that we then auto archive the current current?

[mattbrailsford]

Started a PR for this #28

I think there is a little crossover with #27 as that will need a -c flag to denote the upload should become current. Once that is introduced, we can use that as well to make sure the current "current" is archived.