Are there any docs on the hooks available within .aptible.yml? I see that before_release is referenced throughout the docs, but is there an after_release?
I think an after_release would be for valuable post-successful-deploy tasks, like notifying New Relic of a code deploy.
Good catch; I don’t think there is authoritative documentation for .aptible.yml, but at this time, before_release is indeed the only option.
We’ve had quite a few requests for an after_release. One thing we’ve been discussing internally is whether we should:
before_release.Curious to hear your thoughts on this!
I think the quoted approach is a good next step. It seems extensible (a lot of integrations have CLIs or at least expose an HTTP API that can be curl-ed from an after_release), and very close “to the deploy”, if you know what I mean. Moreover, while Zapier is a very useful service, I wouldn’t want using it to be a requirement for the construction of a deployment pipeline.
Hope this helps! Very curious to hear where y’all take this.
– Dan
Thanks @dleve123; this feedback is very helpful. We haven’t started working on this yet; but we’ll be sure to let you know if / when we have something!
@thomas what environment are the before release hooks run in? What environment variables are available?
@alansempre the environment is going to be that which you’ve specified via your app configuration. We don’t currently inject other environment variables here like we do at runtime (e.g. things like APTIBLE_GIT_REF, but that feels like an oversight and it’s something we’ll plan to fix soon).
@alansempre FYI, before_release hooks now run with the same environments as app containers (and SSH sessions), so you’ll now have access to e.g. APTIBLE_GIT_REF, etc. If you’re unsure what variables are available, the easiest approach is to use aptible ssh and run env!
Thanks. I think it would be helpful to have references to the app and service names and maybe the deploy operation ID.
hey @alansempre, can you share your use case for those? We’d like to avoid proliferation of too many variables (after all, you can always add yours via aptible config:set), but if something is broadly applicable, we could consider adding it.
Note that the service name won’t ever show up in the before_release environment, since that runs independently of services.
I was thinking the app or service name might be useful for deploy hooks used for notifications. Is there any other identifier that can be used that might be stable across deploys other than setting an env variable per app (looks like there is an APTIBLE_RESOURCE_HREF with an identifier)?
If you need a unique identifier, then APTIBLE_APP_HREF is your best bet - this will be href of the app in our API, which is guaranteed to be unique across all apps (the ID in there is — as you’d expect — the app ID).
I would suggest not using APTIBLE_RESOURCE_HREF for this. Currently, that is the app href, but this might eventually change to something else (this variable references what Enclave sees as the “owner” of the container and its associated resources, and while that’s currently the app for these containers, that could eventually change).
Hey there,
Just a quick heads up that .aptible.yml is now documented over here: https://www.aptible.com/documentation/enclave/reference/apps/aptible-yml.html
As for the various environment variables Enclave includes, they’re documented here: https://www.aptible.com/documentation/enclave/reference/containers/environment.html#enclave-metadata
thomas thanks a lot for the links, found a lot of useful information (never thought that sitting home doing nothing but searching for onlinepharmacyreviews.org because of my health issues can be anyhow useful). would you mind if i might have some questions for you? thanks, i’m new here and trying to get used to the site and you people! thanks again!
any updates on adding after_release ? we are looking for this functionality to avoid the extra step of having to SSH into the server to run post_deploy scripts / tasks.