The previous method sometimes truncated the sha, depending on how the app was deployed. Using the long sha will ensure that the value is stable, regardless of the deployment method.
Closes#6770
refs/heads/master cannot be updated to an annotated tag per se; the rev
given must first be resolved to a commit. ^{commit} recursively
dereferences the rev until a commit is found.
Resolves#6737 and test failure:
# bats --filter annotated-tag tests/unit/git_3.bats
git_3.bats
✗ (git) git:sync existing [--no-build annotated-tag]
fatal: update_ref failed for ref 'refs/heads/master': cannot update ref 'refs/heads/master': trying to write non-commit object 6399bed673f513332f3d5d99e777e0262f42404c to branch 'refs/heads/master'
While this might not seem super intuitive, the key is mostly related to git management, not the ssh-keys we currently use to add/remove access to push to dokku.
The shorthand is more prevalent in this codebase, and is something that bash supports, so we should just use the same thing everywhere.
Note that we do not use shorthand redirect in Makefile as shell parsing is a bit different in Make and the shorthand redirect doesn't seem to be properly supported, causing CI errors.
Previously, we created this weird bare repo that didn't do set all the normal git config. This change switches to cloning the local temp directory, fixing the `receive.denyCurrentBranch` property that blocked pushing to this weird bare repo after calling git:from-image or git:from-archive.
Additionally, since we now use a git clone, we set the default branch correctly, ensuring git pushes later on that branch work as expected (and not on master if it was customized prior to app creation).
Closes#5601Closes#5662
This was necessary on Ubuntu 14.04 (and maybe 16.04) due to using a version of Dokku older than #2699, so we can safely drop the support here as we haven't supported either in a few years.
This ensures the value is correct, where previously it was computed based on a file - and therefore did not distinguish between git:from-archive and git:from-image.
Closes#4464
This label is otherwise missing, causing tooling that might want to know about it's pre-existing labels - specifically, docker-image-labeler - to fail to run as expected.
The previous tar support lacked the ability to track changes between tarball deploys. Critically, it also failed to be handled correctly when there was _also_ a git deployment done on the app, resulting in odd deployment states depending on the angles of the moon and the sun in the sky.
Rather than try to "fix" this through some hokey mechanism, importing the tar file contents into the git repository is preferred, as then the user can refer to the repository for commit history.
Additionally, we add support for non-tar files (tar.gz and zip), enabling deployments from systems that do not create tar files, such as Github (their tarball url is a tar.gz file).
Finally, this deprecates the tar plugin, and sets it to be removed in the next minor release (in addition to the tags plugin).
Closes#3458Closes#4207
The new command superscedes the previous tags plugin, and integrates docker image deployment with the general build process.
While `docker image load` is not supported, this otherwise completely handles all previous workflows supported by the `tags:deploy` command, while doing so in a much easier to use interface.
Closes#4296
