feat(archive): archive package support WIP

noelmcloughlin commented 3 years ago

PR progress checklist (to be filled in by reviewers)

[x] Changes to documentation are appropriate (or tick if not required)
[x] Changes to tests are appropriate (or tick if not required)
[ ] Reviews completed

What type of PR is this?

Primary type

[ ] [build] Changes related to the build system
[ ] [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
[x] [ci] Changes to the continuous integration configuration
[x] [feat] A new feature
[ ] [fix] A bug fix
[ ] [perf] A code change that improves performance
[ ] [refactor] A code change that neither fixes a bug nor adds a feature
[ ] [revert] A change used to revert a previous commit
[ ] [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

[x] [docs] Documentation changes
[ ] [test] Adding missing or correcting existing tests

Does this PR introduce a `BREAKING CHANGE`?

No.

Related issues and/or pull requests

Describe the changes you're proposing

Being able to deploy from an archive (tarball, zip) is just as important as a Linux package (RPM, DEB) because most open source software is released by tarball in the first instance (i.e. GitHub releases). Archive package is also the best way to support multiple GNU/Linux since the workflow is identical across all Linux'es.

Pillar / config required to test the proposed changes

None needed.

Debug log showing how the proposed changes work

Travis is passing: https://travis-ci.com/github/noelmcloughlin/template-formula/builds/203168645

Documentation checklist

[x] Updated the README (e.g. Available states).
[x] Updated pillar.example.

Testing checklist

[x] Included in Kitchen (i.e. under state_top).
[x] Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
[x] Updated the relevant test pillar.

Additional context

Travis is passing: https://travis-ci.com/github/noelmcloughlin/template-formula/builds/203168645

daks commented 3 years ago

Just a comment (already discussed elsewhere IIRC): do we want the template-formula to have all possible use cases for formulas? If we do, how do we make it simple for a formula creator to only use a subset of those?

Because having all those functionalities inside template-formula means that formulas created from it will have those, and it may complexify development and usage.

noelmcloughlin commented 3 years ago

A separate branch would be okay for me. When I clone the template formula and run convert, I usually delete package and subcomponent directories and add archive and archive/alternatives. Linux Packages are not very useful in 2020, tarballs and binaries are increasingly the standards. I sometimes raise these PRs (i.e #https://github.com/saltstack-formulas/template-formula/pull/195) to get stuff which is repeated and useful across many formulas into template-formula (a central place), and PR gets stuck on these questions and after a few weeks, I just close the PR (and try again six months later). I understand there is a line in the sand at the moment, but only supporting Linux packages are not very useful to me, or having to repeat stuff in PRs that template-formula does not accept.

noelmcloughlin commented 3 years ago

To answer the question the common cases should be supported, but not all cases.

noelmcloughlin commented 3 years ago

Closing - will try again in future PR sometime.

saltstack-formulas / template-formula