Custom domain pointing to latest tag in repo

[woodsae]

I currently have a custom domain set up to point to my master branch. I would also like to have a consistent staging environment URL, but having a long-lived staging branch would introduce unnecessary overhead to our development process. The way I have done this in non-Amplify projects is to have the production environment be a deployment of the latest tag in the repo. This would then leave me free to make the master branch a pre-production staging environment with a consistent URL.

I would like an option to set my custom domain to point to a build of the latest tag in the repo. Would this be possible?

[swaminator]

@woodsae thanks for the feature request. Some questions:

1. Do you want to have a flow where you can create a branch deployment from a specific tag? (e.g. release)
2. Can you tell us what tags you use specifically in your workflow?

[woodsae]

Hi @swaminator, thank you for the response.

When I want to deploy to production I would make a tag in the format v1.0.0, so any tag starting with v means a production tag. I would like my custom domain, app.trabr.com, to point to a deployment of the latest tag. So when I make a new tag starting with v, a deployment would happen and that code would now be serving production.

Does that make sense?

[woodsae]

Hi @swaminator , do you have any thoughts around my previous comment?

[jsw]

I'm looking for something similar. We have our dev environment connected to the master branch and our prod environment connected to the prod branch. Maintaining the prod branch is not clean. All we want to do is promote the master branch to production. In our non-Amplify apps, we are able to simply publish a GitHub release, which triggers a GitHub Action to deploy to prod. Being able to connect an Amplify env to a tag or a release, or the latest tag as @woodsae suggests, seems like an improvement over maintaining separate branches for different environments.

[woodsae]

@swaminator Is there any movement on this?

Just to be clear, this is what I want to accomplish:

• Dev branches use the PR Preview functionality and each have a unique URL
• Staging points to the master branch and has a consistent custom domain URL
• Production points to the latest tag/release in Github and has a consistent custom domain URL

This would be hugely beneficial if we can accomplish this, because we have a native iOS app that exposes some web functionality in a wrapper and if the staging URL is constantly changing because of PR previews it means we have to keep updating the build just to test functionality. And it would be too much extra effort to always maintain a staging branch.

[MichaelRoberts-FlashParking]

I'm looking for the same thing. I was able to use the "Incoming webhooks" feature to get amplify to only builds the app when a "release" event is triggered in GitHub, but it's still building the latest version of the branch, making reverting to a previous release/branch in GitHub pointless. It would be great if Amplify could be configured to just track the latest tag/release.

[GooBall]

I could really do with this too. I need to be able to select a new tag once it has been built to just point the domain over to the new code. This would also then allow for rollback if a new tag introduces an issue to a production environment.

I understand I could do this with branches. But tags exist in GH and other repo management solutions for the express purpose of being able to target specific versions.

[jose-fmeyer]

Would really appreciate to be able to use Git tags as well. Many deployment tools use the release artifact as the source of truth for deployments and rollbacks, and relying only on a branch for me seems a bit error prone. Rolling back with amplify currently isn’t easy as well. Reverting the code in the master branch doesn’t seem to be a good option .

Any ideas when this could be tackled?

[nirradi]

Releasing and deploying on new git tags is very common, so this seems to make a lot of sense to have.

One workaround that seems pretty straightforward to me is having your CD (jenkins/github actions, etc) force push to the deployment branch any time a relevant tag is created (not master, more like "release-amplify" or something) . Rolling back to a different tag should be possible in a similar fashion. Proper branch rules in github could make sure that this branch isn't updated in any other way.

Does that cover this use case?

[rchavez-neu]

+1 for the request(s) for being able to connect Amplify to a specific tag/release for deploys and rollbacks. There hasn't been much feedback/response on this from AWS yet @swaminator , any idea of when/if this request might see some action?

[croossin]

@swaminator Bumping this thread... any updates?

[ngeprint-io-team]

@swaminator I think this is a must have feature. AWS CodeBuild support this feature, why Amplify can't?

[ric-sapasap]

Any updates on this feature?

[dnoji]

@swaminator Any updates? 🙏

[truecolintracy]

Also looking for this feature coming over from github actions.

[rmakovyak]

@swaminator this feature is also something our team is looking for

[jeff-accountably]

+1 to this, I currently manage three branches to accomplish this (dev, staging, and prod). Managing a single branch with tags would be so much easier.

[david-j-davis]

+1 to this

[crow7m]

+1

[mswezey23]

+1 Been desiring this feature for awhile.

Any updates?

[scotnick]

+1 same here! would really love to see this feature! is there any progress on that?

[mkelitz]

+1 same need here.

[erudenko]

my +1 for this

[cbetori]

+1 need this feature

[devinhaynes]

+1 Much needed feature

For those looking for a workaround, I was able to deploy the Amplify webhook through Github actions.

[alind-ch]

@swaminator any updates? much anticipated feature.

[mswezey23]

Still awaiting GitHub tagged version support.

Any updates on when this will or will not be supported?

[ThibaultLengagne]

+1 same need

[walinsta]

+1

[nroehling]

+1

[SimonStAmand]

+1

[ki0]

+1

[nkpremices]

+1

[mits87]

Any updates on this feature?

[lucassarcanjo]

+1

[djmisha]

+2

[pmakow]

Is there any update on this feature? My team also need it.

[darekraczka]

+1 It's a very needed feature

[sszlaga]

+1

[mstali02]

+1

[caseyhenderson]

+1 - this feature would be extremely helpful for my organisation.

[cgaubuchon]

We sort of solved this by creating a GitHub action that manages a merge from our main branch into each environment branch that Amplify currently requires. While it does not achieve exactly what the original request was here it allows us to run trunk-based development. It does the following:

1. Action is triggered when tagging a deployment on main
2. Creates a temporary branch from whichever environment branch Amplify is connected to, such as "stage"
3. Merges main into this temporary branch and prefers the changes in main to avoid any merge conflicts
4. Opens a PR and merges with relevant commit messages
5. Deletes the temporary branch used in the action

True tag-based deployments would still be a great addition to the Amplify platform, but this is working well enough for us. Where we still have environment branches, but they are locked down from usual git actions, and only the GitHub action controls what goes in/out.

[mkaliberda]

4 years later, no response on so critical feature request

[tosh79kt]

+1

[juanchojbarroso-mymoid]

+1

[mcetat]

We sort of solved this

Would it be possible to provide an concrete example of how you solved that? We're having the same problem currently, and I could not figure yet out a way to make that workflow automatic.

[mswezey23]

Any updates from AWS on this?