Everytime I try to set up automatic deployment for a qa branch, the UI doesn't give me any errors. However when I refresh the page, the deployment settings goes away and it asks me to enable for the master branch.
Before Refresh:
After Refresh:
Fixed once I pushed my code to the actual repo
Related
I have an Teamcity server with a bitbucket server repository. On the Teamcity is a build pipeline which is used to validate pull requests setup. And basically it works as expected. But while new pull requests are triggered within a minute, when I commit changes on a pull request it can take up to an hour until Teamcity has the changes in the build configuration page. As soon as it does find them, it triggers the build as expected.
It also doesn't make a difference if I select the "check for pending changes" in the Actions menu.
Strangely on my other build pipline, which builds changes on the master branch new commits are triggered within the minute as well.
Pull Request Build Feature:
My branch specifications:
The "Changes checking" settings:
And the trigger:
We use TeamCity Professional 2019.2 (build 71499)
EDIT1: I just realized that there are two different views for changes: one for the branch and one for the pull request. The changes do show up in the branch for the pull request very quickly, but not in the one for the pullrequest.
Branch view:
Pull Request view:
As a reference those screenshots where made 16:32.
EDIT2: I used this article to set it up: https://www.jetbrains.com/help/teamcity/2019.2/pull-requests.html
EDIT3: I just found out that I can trigger the build with browser the pull request on the Bitbucket Server page. No idea how that works though.
It seems this is by design of Bitbucket Server:
https://community.atlassian.com/t5/Bitbucket-questions/Change-pull-request-refs-after-Commit-instead-of-after-Approval/qaq-p/194702
TLDR: The Refs on pullrequest branches are not updated immediately, due to performance consideration. The easiest way to trigger it is to view the PullRequest on the Bitbucket Server website.
Comments, and ref updates to the master will also trigger it when I understoot that correctly.
I'm producing an app in Heroku using Heroku Pipelines. I took over the project from someone else, so the current production app was created from a repository I'm not under control of. I pushed my new version of the app to the 'review' stage directly from Github. Now I want to promote my review app to the next stage in the pipeline: 'staging'.
I tried:
heroku pipelines:promote -r staging --app [nameofmyapp]
Heroku returned:
Cannot promote [nameofmyapp] from 'review' stage
Any ideas as to why I am not allowed to promote my review app?
Review apps cannot be promoted to the next stage.
They are created automatically when a Pull Request is opened, and deleted when it's closed or merged.
The way to promote that deployment to the next stage is to merge the pull request.
I am investigating adding an app.json file to my heroku pipeline to enable review apps.
Heroku offers the ability to generate one from your existing app setup, but I do not see any way to prevent it from automatically committing it to our repository's master branch.
I need to be able to see it before it gets committed to the master branch because we require at least two staff members to review all changes to the master branch (which triggers an automatic staging build) for SOC-2 security compliance.
Is there a way that I can see what it would generate without committing it to the repository?
I tried forking the repo and connecting the fork to it's own pipeline, but because it did not have any of our heroku add-ons or environment, it would not work for our production pipeline.
I am hesitant to just build the app.json file manually - it seems more prone to error. I would much prefer to get the automatically generated file and selectively remove items.
As a punchline to this story, I ended up investing enough time into the forked repository on it's own pipeline to demonstrate a POC
When you generate your app.json file, it should take you to a secondary screen that has the full app.json in plaintext at the bottom.
Why not open a PR with its contents in your project root. Once it's detected on the repository Heroku shouldn't ask you to regenerate it again.
My workflow encompasses the following steps:
Git push (to BitBucket or GitHub depending on the project).
BitBucket/GitHub is integrated with CodeShip, tests are run.
If tests are ok, CodeShip automatically deploys to Heroku.
Everything works fine when, by pushing to the remote repo, the deployment tasks are triggered which ends up with the new version going live when everything is ok.
My question is:
Sometimes, I simply do a git push heroku master which defeats the whole purpose of this workflow.
How can I prevent it from happening? Is there a way to make Heroku only accept the deploy when the source is CodeShip?
After looking around for quite some time, I noticed that there are a some ways to accomplish this, all of them related to simply not giving access to the Heroku Account for the developer:
If you're a single developer ("one-man / one-woman show"):
Do not add the Heroku Remote to your Git Repository. If it is already added, remove it. That way you're not going to push to it by mistake.
If you're managing a team:
Do not give the team a user/pass to access Heroku Toolbelt. That way, the only remote repo they will have access to should be GitHub/BitBucket/Whatever.
You could just create another branch called dev and push to that branch your changes and when you are ready to deploy to heroku merge changes into master branch.
I just came accross your issue and this is what i did as quickest resolution
[FYI - I am not looking to upgrade our Heroku account to Enterprise to take advantage of app grouping. We are a small team]
I am a collaborator on a heroku app. I was tasked with setting up dev-staging-production environments for the app and I am getting confused on how to setup Auto Deploy correctly with the GitHub-Heroku integration guide. I have been already given admin access to the original git repo.
From the 'owner' account on the production app I created two separate apps (dev and staging).
Now, I have 3 apps that I am a collaborator of:
(1) app.domain.com
(2) app-dev.domain.com
(3) app-staging.domain.com
I have created 3 remotes pointing to the 3 generated heroku-git repos:
live
dev
staging
I can push to the 3 Heroku apps easily by:
git push live master
git push dev master
git push staging master
BUT I want to setup auto-deploy for dev-staging apps.
I have pushed an "auto" branch onto dev and staging remote. My intention is for Heroku to detect pushes to that branch and "auto" deploy the code. But, heroku only detects pushes to "master" branch afaik.
git push dev release auto
git push staging release auto
But when I go to administer the Heroku dev-staging apps I only see the "master" branch in the Auto-deploy section. Shouldn't I also see the "auto" branch? Is the reason I am not seeing it because I didn't push auto as a remote branch on the ORIGINAL git repo? In which case, how do I structure this stuff as code lives in 2 separate environments (Heroku repo and GitHub repo)?
Ultimately, the plan is to setup some form of Continuous Integration and get tests run before releases happen across the dev-staging-production zones.
Am I overthinking this or is there a better way to get this stuff working? Appreciate it!
Heroku only tracks changes on the remote master Branch.
https://devcenter.heroku.com/articles/git#deploying-from-a-branch-besides-master
To push your dev branch to the Heroku master remote branch:
git push dev release:master
You may need to use the -f flag to force push (be careful!)
I think auto deploy on Heroku works only on default branch (usually named master), and you probably want to look into Heroku feature called pipelines. I've not used it myself yet and it's in beta stage, but it sounds like exactly what you're looking for. Not sure if I read it right, but it sounds like you created 3 individual projects, instead of branches in 1 project? How do you manage moving changes from one stage to another?
As for the CI setup I guess it depends on the kind of testing you're doing and the workflow. I'm in the middle of creating such process in my workplace, and what I will be proposing is as follows:
Devs develop and test on their local machines on feature branches before commiting and merging onto DEV branch
Commiting or merging onto the DEV branch triggers CI server, runs the build and perform PHPUnit and Behat tests
Successful build is being deployed to a server (possibly Heroku or any hosting provider that will support automated deployments) for QA.
Once tested and approved we can move the code onto STAGING branch repeat CI proccess and on success move to MASTER and go live.
We're using gilab.com to host our project and perform tests (CI server is included as standard even with free account), deploy dev and staging state for QA to Heroku, and finally host live version with a dedicated enterprise level provider.