skx / deployr Goto Github PK

That would disable execution/uploads, and imply -verbose.

If you use CopyFile a.txt /tmp/a.txt and a.txt doesn't exists on the local system, deployr silently ignores the problem. This is confusing. It maybe a good idea to fail, if the local file is missing. An impolite solution could look like this:

index 26e15b0..e3f502b 100644
--- a/evaluator/evaluator.go
+++ b/evaluator/evaluator.go
@@ -422,6 +422,11 @@ func (e *Evaluator) copyFiles(pattern string, destination string, expand bool) b
                return false
        }
 
+       if len(files) < 1 {
+               fmt.Printf("Local file missing: %s\n", pattern)
+               os.Exit(11)
+       }
+
        //
        // Did we receive more than one file?
        //```

Via #8:

Add support to pass the -i in "ssh" for the private key (could be different in some use cases)

Since this is what I use the most.

When a command fails, the only information we have is the return code. This makes it hard to know why that command failed.

$ deployr run -verbose ./deploy.recipe 
Run("program_who_failed")
Error running program
failed to run command 'program_who_failed': Process exited with status 127

I would be useful to also have the stderr.

Run("program_who_failed")
Error running program
failed to run command 'program_who_failed': Process exited with status 127
bash: program_who_failed: commande inconnue... # stderr

versioning and rollback would be nice
you might want to take a look at harp

https://github.com/bom-d-van/harp

Thanks for writing deployr!
When using Sudo in a recipe deployrasks for the password - all fine. But it echos the typed password on the terminal. I think this is dangerous and very unexpected behavior.

We connect as one user - often root - and have no facility for doing things as other users. Short of the obvious:

Run "su - nobody -s /bin/sh -c /usr/bin/id"

It might be nice to allow "Sudo" as an alternative to "Run". Of course if we're prompted for a password it become complex again, quickly..

If we do go down this road we'd need:

• Sudo "command"
• SudoIfChanged "command"

At that point it might be worth taking a step back and removing IfChanged, instead adding If support. So we could just run:

if ( CopyFile .... )  {
   Run "blah"
   Sudo "blah"
}

Of course that's a slippery slope, but perhaps one worth sliding down. Comments welcome.

Migrate the github actions to the new YAML-based syntax, rather than the HCL.

Right now:

 CopyFile blah/1.conf /etc/blah/conf.d/1.conf
 CopyFile blah/2.conf /etc/blah/conf.d/2.conf
 CopyFile blah/3.conf /etc/blah/conf.d/3.conf

Would be better if I could allow:

 CopyFile blah/ /etc/blah/conf.d/

This is a compromise because allowing looping-constructs would solve this problem, but that would be a considerable rise in complexity.

I've got a couple of recipes which are almost 100% identical, and I launch them like so:

 deployr run ./recipe.dev

vs.

  deployr run ./recipe.prod

The only difference is the release number "1.2" vs "latest", and that I copy files from:

 CopyFile ./dev/etc/systemd/.. ...

If I were to define a variable I could then use:

 CopyFile ${ENVIRONMENT}/etc/systemd

But of course I'd want to set that in the file so that I had:

 Set ENVIRONMENT "production"
 Set RELEASE "1.2"

And if I added a "--set RELEASE=1.2" I'd need to make sure that wasn't overridden. In short variables set on the command line should be read-only and not changed.

When deciding when to use SSH Agent, the environment variable SSH_SOCK_AUTH is checked. This works fine on Unix-based systems but not on Windows. Given that the simplessh package uses pageant, it would be good if the Windows version checked for pageant when deciding to use SSH Agent.

For my own personal needs I think this project is pretty much complete as-is, despite the young age.

• There might be bugs, which will be fixed.
• There will almost certainly be improvements to the code-quality, and the addition of tests, but from an end-user perspective these are internal details which don't matter.

Anyway if the documentation is lacking/incomplete, or you have feature-requests/questions, please do report an issue :)

We should use a lexer & parser to process our input files.

There would be no functional change, but we'd be able to report upon errors (unknown commands, and bogus-arguments) when we read the recipe-file.

We can then also add tests for our parser, as at the moment we have zero tests.