itsapi / post-receive

The scripts we use to get stuff in the right place on the server.

Post Receive

These scripts are run after code is pushed to the server. They compile everything and deploy to the correct location.

github-listener runs this script for each repository after fetching the files from Github.

index.js is run in this directory, processing files as specified in options.json. The files are then transferred to the output directory.

The options.json takes a number of different options for build steps:

• build_cmd: list, a list of shell commands to be run in repository root at processing stage
• copy_from: string, copy the contents of this directory to the output directory
• copy_to: string, the directory files should be copied to after processing
• start_cmd: list, a list of shell commands to be run in output directory after processing
• ignore: list, a list of files and directories in the output directory that should not be overwritten/deleted
• url: string, a link to be displayed after processing on the github listener output
• email: list, a list of email addresses to send error messages if the build fails

Host specific options

The options.json can have host specific options under the hosts property. This is useful for moving processed files into different output directories on different environments.

Example:

{
    "copy_to": "/home/git/deploy/post-receive",
    "start_cmd": ["npm install"],
    "hosts": {
        "oliverfaircliff": {
            "copy_to": "/opt/ptr"
        }
    }
}

Documentation

See the DOCUMENTATION.md file.

Contributing

1. Create an issue with your bug or suggestion
2. Fork the repository
3. Make your changes in your fork
4. Create a pull request here, referencing the original issue

License

See the LICENSE file.

post-receive's Issues

Error function should use repo name

The error function should take a repository name from GitHub Listener to make the error emails actually useful.

Example error email with path being passed into error function:

/home/git/deploy/processing failed to build correctly at Mon Feb 9 12:29:26 2015
Error message: grunt failed

Repository's location on the server

Wouldn't it make more sense to put the users folders, containing the repos, within a folder? This would clean up the home directory a bit and make it more obvious what they are. Maybe they could even go in the post-receive folder?

Simplify options

Remove node specific options and rename them to make them easier to understand.

Modularisation

All the initial Git stuff is done in the bash script at the moment, which then calls a python script to do the processing. Would it not be better to do the Git stuff from within the python script. This would also make it easier to detect errors, for example at the moment if the repository doesn't exist it errors once on the cd, then twice more on two git commands because it is not in the repository. It would be better if we stopped after the cd failed.

copy_to is relative to copy_from?

Is this correct behaviour? Should it be relative to repo root?

Dev / Live options

We could add a feature to use different options depending on whether we are on the server or dev machine. For example you might want the files to be outputted somewhere else on your dev machine.

Travis CI Tests

We should have a Travis project that runs some tests and only triggers itsapi/github-listener when the tests pass.

Move run.sh into its own repository

To help with Modularisation #4, we should move run.sh into its own repository itsapi/github-getter as it gets more developed. This will allow the system to be more modular. More information itsapi/github-listener#13

Allow custom build systems

We should allow a custom command instead of just a grunt boolean.

Improve `build failed` emails

The build failed emails don't give much information currently.
Perhaps we can show some command outputs or a link to GHL.

Node Modules

Now that github-getter is not keeping node_modules, the dependencies are being re-downloaded every time a project runs npm install. Not really sure how this can be helped...

Replace Keys ignore

We need to ignore node_modules in replace keys for repositories not using grunt.

Perhaps use package.json to get build command

Ref #12 we could use the package.json to get the build command:

{
    "scripts": {
        "build": "gulp"
    }
}

Branch

There could be an option to specify branch in options.json

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Perhaps escape ANSI colour codes

It would make output for ghl better.

Make it a class

It will make settings nicer:

• logging flag to silence logging
• cwd to restore original cwd
• store options for easy access in all methods

Node and grunt enabled together

Currently we do not allow node and grunt to be enabled together.
The reason we are doing this is because they both use a package.json and if grunt is enabled the package.json is not copied to the destination directory.
I don't see a reason why we can't remove package.json from the ignore list and allow both grunt and node to be enabled together.

We will need to consider a few things though:

• We should put grunt dependencies in devDependencies and run npm install in the processing directory if grunt is enabled (and of course run grunt)
• We should then run npm install --production in the output directory once the files have been copied to only install the dependencies and not the devDependencies
• We will also have to put in some logic to copy the package.json if there is a src directory (because only the contents of the build directory will be copied)

Improve test coverage

We need to test more of the options and host-specific options. Also email is not tested (although I don't know how we could test that).

Grunt Failing

When Grunt fails it should abort, otherwise you end up with a broken site when it moves half processed files into the ouput.

Javascriptify?

It will integrate better with GHL

Nodemailer

The from address needs to be set for it to send emails. We need to think about what form the address should take.

Output Ignore List

The ignore list is not really relevant to the repository and it is a bit of a nuisance to change it. It might make more sense to have an ignore file we can put in the output directory with a list of directories we want to keep here, that way the information is kept right next to the directories it is relevant to.

npm update instead of npm install

Because we cache modules in node_modules, running npm install will not update the dependencies in node_modules. Running npm update will install new modules from the package.json and update installed modules to the version specified in package.json.

Changes in #16 will make this issue obsolete.

Modular Build Systems

Now that the node option is gone, all the commands are going in the start_cmd option. We should make an interface to add build/start systems to post-receive that can then be used by specifying them in the options.json.