I'm having issues setting up auto deploy with my github node.js repo on heroku. On the heroku side, it says "Automatic Deploys from master are enabled" and there are no restrictions on my repo for auto deploy on github. I am able to do a manual deploy fine but wanted to see if anyone has run into this problem as well and have a solution. Thanks!
This seemed to be an issue with GitHub as I was having the exact same issue earlier today. I had my heroku app watching my master branch, so whenever a branch was merged into master, a deployment build would automatically kick off. This all of the sudden wasnt happening as of today, however the manual deploys worked as expected as you mentioned.
Seen here https://blog.github.com/ github has addressed some issues in deployment workflows that they have had issues with during today and yesterday.
Related
I have a node.js website that uses Vercel to deploy, and would automatically deploy when I updated the main branch on Github. Everything was working fine until recently and I have no idea what has changed. Except now, even if I try to make a new branch the production branch, Vercel doesn't seem to be updating with those changes either. All my changes are viewable in local development and through the preview button on Vercels site itself. Has anyone run into a non-responsive Vercel deployment tool before?
Okay so i recently finished my portfolio and i wanted to host it on netlify through github but it failed.
Their docs and build log are so confusing that i do not know how to trouble shoot the problem. However, when i ran
npm run build
locally on my system and then i dragged it onto netlify, it worked.
I'm not saying i cant just keep doing this for all my websites but i would like to know any potential reason as to why it didn't work when i tried it from github.
For context, the current node version is 16 and the one i am using on my system is version 14. I'm not sure whether that is enough to affect the build from github but i just thought i would mention it. if However, that is a reason as to why it isn't deploying from github then how do i fix it?
Is it throwing errors when you are deploying your site from GitHub or what? I am sure you have created a GitHub repository and logged/signed into netlify with GitHub (and authorize it). And from there(netlify's dashboard) to Team overview > Add new site > Import an existing > GitHub (it will again ask for authorization) > Pick a repository > and > Deploy site (with default settings).
This should pretty much deploy your website without any troubles. Now you can also try commit to your GitHub repository and it would automatically trigger deploy of your website on netilfy (what you call a continuous deployment).
well I have a problem with heroku (PasS), I am launching my first project with Laravel and I'm currently making constant changes,
I understand that every change I make in development I have to use git and push heroku to send to production and also to see the changes in vue.js I have to execute a command in heroku bash, now my problem is because the changes I currently make it no longer works it is not seen in production, constantly made many commits it will be for that or for the cache I do not know the truth I hope a response please.
Sorry I do not understand you well or maybe it is because of my lack of ignorance since it is my first project that I launch to heroku, However I will detail my problem currently I have two branches: master and production, currently I always work with the master branch and also that's where I push the changes to heroku
Here I show you a message from the list of my commits in the master branch:
in conclusion :
I have created a component in vue.js and when I deployed the application to heroku, that component is not shown and as I said in heroku bash it executed "npm run dev" to show the changes in the front-end, previously it showed the changes it made but over time I stop working
And as I say I think it is for making many commits
I have a solution containing a .net mvc website, and a webjob.
I deploy using git - so on git push to azure, my website is upgraded. I'm now just adding a console application that is going to be run on a schedule. I'm trying to work out how to deploy this with the website when I git push, but I'm not sure how to do this.
I know I could create a folder website\app_data\jobs\triggered\webjob and copy the files into there (say from a post-build event on the webjob), but that would mean I would need to commit all those files to the git repo for the deploy to pick them up - which would also mean that every time I build, Git would be prompting me to commit them again - ugh.
Is there a nicer way to do this - where I can just push my repo to azure, and it will deploy my website correctly AND my webjob?
Thanks
Yes, you can do this without having to put the actual EXE's and project output into the folder explicitly. This blog post from the Azure Blog documents the workaround to enable Git or command-line deployment of a web application inclusive with WebJobs.
http://azure.microsoft.com/blog/2014/08/18/enabling-command-line-or-continuous-delivery-of-azure-webjobs/
If this doesn't unblock you please post an update and I'll help walk diagnose any other issues you run into. You may also want to update the WebJob publishing NuGet to the most updated one on NuGet here: https://www.nuget.org/packages/Microsoft.Web.WebJobs.Publish/1.0.2
As of 9/15/2015, this appears to be as simple as some context menus inside Visual Studio.
If you want your WebJob to automatically deploy whenever your Website is deployed, in Visual Studio you can right-click on the Website and select "Add->Existing Project as Azure WebJob".
More details here, in particular the "Enable automatic WebJobs deployment with a web project" section.
I was struggling with this, but I've got it working now.
It appears that WebJobs.Publish 1.0.2 must be used. 1.0.1 was not working for me. Worked as soon as I updated.
I had also tried adding webjobs.props files as indicated here by David Ebbo, but that didn't work for 1.0.1 and I've now removed those files and it's working under 1.0.2 without them.
Using WebJobs.Publish creates a webjob-publish-settings.json (in the webjob project) and a webjobs-list.json (in the MVC app) and that would seem to be all that is needed.
Only thing that does not work is creating the schedule for a scheduled job. Continuous and Triggered jobs deploy just fine. There's a thread here where David Ebbo mentions that this is a current limitation.
I've been successfully using Git deploy (via Kudu) to a couple of Azure websites (e.g., beta/prod) for several months, and it's worked quite well. Starting today, I noticed that when I push to the appropriate respective git branch, my Azure websites will supposedly deploy - i.e., the deploy kicks off, everything builds, all my tests run, and the Azure management portal swears up and down that it's deployed my website - but ... nothing happens. My websites don't change. (Beta and prod pull from different branches of the same git repo, but no matter which I push to, none of the changes included in the latest push show up on either website.)
There are no errors or any other indication of a problem in the logs. The Azure portal detects the git pushes, runs the deployments, and swears that they've happened successfully. But the changes - some very simple ones, i.e., text on a certain page - simply aren't there.
This is the sort of thing that I'd normally contact Azure support for, but my subscription doesn't include tech support :-(. The Azure site recommends asking here on SO, and hence my post.
Any suggestions for further troubleshooting this?
Well, I don't know what was triggering the problem, but resetting the website - by adding a bogus key/value pair to the configuration, and saving it - triggers the website(s) to pick up the changes. Apparently the underlying issue is that the Kudu deploy doesn't seem to be triggering the website to reset itself. I'll add more details in the future if I run into the problem again.
[Edit 2013-10-15 - Today, deploys seem to be working normally again. My guess is that it was some sort of transient Azure bug that's now fixed.]