Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[semver:patch] allow tag deployments by using full path refs #12

Closed
wants to merge 1 commit into from
Closed

[semver:patch] allow tag deployments by using full path refs #12

wants to merge 1 commit into from

Conversation

a14m
Copy link
Contributor

@a14m a14m commented Jul 27, 2020

This edit is just more verbose about which reference is being pushed and to which remote

<refspec>: If <dst> doesn’t start with refs/ (e.g. refs/heads/master)
we will try to infer where in refs/* on the destination <repository> it belongs based on
the type of <src> being pushed and whether <dst> is ambiguous.
If <dst> unambiguously refers to a ref on the <repository> remote, then push to that ref.

Ref: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-push.html

The added benefit of this edit is that we can now deploy both branches and tags based on the definition of the parameters.branch

ex:

  • refs/heads/master will always deploy the master branch
  • $CIRCLE_BRANCH is the same default behavior as now
  • refs/heads/$CIRCLE_BRANCH is the same default behavior now (same as the previous version)
  • refs/tags/$CIRCLE_TAG is a "hacky" way for deploying tags to Heroku

Fixes: #7
Safer than #8

As when a new repo is created on heroku, the command used in
#8 would fail with the following error

hint: The <src> part of the refspec is a commit object.
hint: Did you mean to create a new branch by pushing to
hint: 'v2.0.0^{}:refs/heads/master'?

Backward compatible but the naming of the variable could be changed in a later release to indicate that it's taking a reference path to deploy on the refs/heads/main heroku branch

This edit is just more verbose about which reference is being pushed and
to which remote

> <refspec>…
> If <dst> doesn’t start with refs/ (e.g. refs/heads/master) we will try to
> infer where in refs/* on the destination <repository> it belongs based on
> the type of <src> being pushed and whether <dst> is ambiguous.
> If <dst> unambiguously refers to a ref on the <repository> remote,
> then push to that ref.

Ref: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-push.html

The added benefit of this edit, is that we can now deploy both branches
and tags based on the definition of the `parameters.branch`

ex:
- `refs/heads/master` will always deploy master branch
- `refs/heads/$CIRCLE_BRANCH` is the same default behaviour now
- `refs/tags/$CIRCLE_TAG` is a "hacky" way for deploying tags to heroku

Fixes: #7
Safer than #8

As when a new repo is created on heroku, the command used in
#8 would fail with the
following error

```
hint: The <src> part of the refspec is a commit object.
hint: Did you mean to create a new branch by pushing to
hint: 'v2.0.0^{}:refs/heads/master'?
```

Backward compatible but the naming of the variable could be changed in a
later release to indicate that it's taking a reference path to deploy on
the refs/heads/main heroku branch (that isn't ignored)
@a14m a14m changed the base branch from master to Alpha July 27, 2020 15:45
@a14m a14m changed the base branch from Alpha to master July 27, 2020 15:50
@a14m a14m changed the title Use the full qualifier name for the branch deployments (allow tag deployments) [semver:patch] allow tag deployments by using full path refs Jul 27, 2020
@gmemstr
Copy link
Contributor

gmemstr commented Jul 31, 2020

We're opting to use #8, as it's a nicer end-user experience for the orb.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deployment with tags
2 participants