| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
WIP! Like, really WIP. Don't test it yet, there's still some work to be done. |
Sorry, something went wrong.
|
Btw, pack show available <pack> shows content count if it's present in the index, but pack show <pack> doesn't have content count for installed packs, because we don't have helper functions for content counting yet. @Kami promised to get it done :) |
Sorry, something went wrong.
Current coverage is 77.11% (diff: 100%)@@ master #2982 diff @@
==========================================
Files 430 430
Lines 21997 21997
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 16914 16962 +48
+ Misses 5083 5035 -48
Partials 0 0
|
Sorry, something went wrong.
|
@emedvedev Yes, I think packs.deploy and it's associated actions can be removed. In fact GitHub pack deployment_event workflow that I added earlier in October does not call packs.deploy and calls packs.install directly. I think with the release of Stackstorm-exchange the bitbucket rule post_receive_webhook.yaml should be removed. |
Sorry, something went wrong.
Once we make the move, that rule and workflow will become a bit simpler, too! action: packs.install input: packs: [ "<% $.ssh_url %>=<% $.deploy_ref %>" ] I'll skim through all the packs to make sure all the packs.install and packs.download references are updated when the packs are moved. |
Sorry, something went wrong.
| pack_formatted = None | ||
| # Try to get the original yaml file because we know | ||
| # how it's stored in the Exchange, otherwise fall back | ||
| # to transforming json. |
There was a problem hiding this comment.
@emedvedev
As I see, we already getting pack meta from index from endpoint: https://index.stackstorm.org/v1/index.json
And then we're downloading https://index.stackstorm.org/v1/packs/github.yaml again with the same meta.
What was initial idea here? Because it seems a bit dirty with all the hardcoding, additional request, regex.
I'm thinking about removing this second pack.yaml part and rely only on get_pack_from_index(pack) meta.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm thinking about removing this second pack.yaml part and rely only on get_pack_from_index(pack) meta.
👍
Problem with json->yaml is that it's not ordered, but that doesn't really matter much.
Sorry, something went wrong.
- `!pack get` - get info about installed pack - `!pack show` - show remote StackStorm Exchange pack - polished & working `!pack show`
|
So it's fixed & Polished & Acceptance tested in Slack.
The Aliases automated tests as well as Integration Tests (e2e, robo) are in my TODO list and will be added, but It's good to merge now to see things in pre-production (packages).
|
Sorry, something went wrong.
|
❤️ ❤️ ❤️ ❤️ LGTM. |
Sorry, something went wrong.
enykeev [10:30]
!pack show st2
stuffBOT [10:30]
@enykeev: Getting back to you about the `st2` pack:
Here's the full index entry at StackStorm Exchange:
{author: st2-dev, description: StackStorm pack management, email: info@stackstorm.com,
name: st2, repo_url: 'https://github.com/StackStorm-Exchange/stackstorm-st2',
version: 0.1.2}
To install the pack: `pack install st2`
If the pack is already installed, I will upgrade it to the latest version, keeping the config.
I'm kinda missing hubot alias before the command, though I'm not sure we can get it now in any sane way. Also, #3051 to prevent different kinds of output formatting for different packs. Other than that, looks good to me. |
Sorry, something went wrong.
| upgrade: | ||
| type: "boolean" | ||
| default: false | ||
| description: "Upgrade the pack if already installed." |
There was a problem hiding this comment.
Wait a second. I don't see us using it in any way. I also don't think we should have something like that to begin with. Can settle to default: true, though.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm not sure what that flag is doing here 😛 Should just remove.
Sorry, something went wrong.
There was a problem hiding this comment.
Don't know where it comes from too. Will remove.
Sorry, something went wrong.
There was a problem hiding this comment.
Hm, but this is interesting.
In future it would be good to have pack install really idempotent.
So if pack is already installed - it won't be reinstalled again, unless some special flag like that specified. Re-downloading/re-installing by default takes time and it's in fact "upgrade" or "reinstall".
This makes sense especially for configuration management tools, when you apply playbook/cookbook, which apart of deploying st2 installs a bunch of st2 packs on the same machine. And it's normal to run same playbook on the same machine several times.
Sorry, something went wrong.
There was a problem hiding this comment.
This is a bigger discussion that applies to package management in general. It will be idempotent if you specify a precise version, and we already support that, but a repeated install is normally regarded as upgrade, we're certainly not alone here. :)
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry, something went wrong.
There was a problem hiding this comment.
Installing + Downloading over and over again (even if it reaches the same state) is not considered really "Idempotent" in configuration management.
If resources is in desired state - we shouldn't repeat the same operation again.
Sorry, something went wrong.
There was a problem hiding this comment.
Fair. They do stay in that state though 😛
Let's make sure we get to that issue after the release, it's pretty important.
Sorry, something went wrong.
Yeah, @enykeev I just verified, and there is no hubot alias variable in context. I bet none could think that it might be useful to have in context. Might be something good to adjust in future. |
Sorry, something went wrong.
|
Nice work everyone! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Aliases for the packs pack:
— pack install for installing a pack or multiple packs (just a minor rework here);
— pack search to query the index;
— pack show to display information about an installed pack, including HEAD location in the git tree (N commits ahead/behind);
— pack show available to fetch information about a pack from the index.
Most of packs.deploy is now obsolete, so I'm removing it and the helper actions for now, but I would appreciate @jjm finding some time to talk it over with me. A thing or two that was possible with packs.deploy might not be covered by our new pack management, and if that's the case, I'm fine with keeping the deploy workflow or breaking it down into multiple actions.
There was a linux pack directory and an action. Inside the packs pack. Apparently, for quite some time, too (I remember @enykeev noticing it). I removed it. Sorry, not sorry.
Some minor cleanups (this PR started as a minor cleanup, actually, but then things just got more and more interesting).