I been using Vercel for quite a while, it's never been a headache for me until now, i'm facing a very weird situation, since yesterday it doesn't matter how many git push i do to my project (it only has one branch, main) Vercel keeps deploying the same old version of it. I got no errors from Vercel, it tells me it's been ok, it's deployed, but it's still an old version of my project.
ps: i'm developing a webapp using nodejs + astro, i think isn't relevant...
I'm running out of possible solutions, I've tried to delete the deployment on Vercel and create it again, nothing works.
Related
I've developed a composer package that's included into many Github repo Laravel projects. It's set to a specific version, but even if I make it slightly looser and set the patch version to be a asterisk for the patch version I still need to run a composer update in the project that requires the package so that when running composer install on a server it installs the correct version.
The issue I'm facing is that when I release a new package version, I've got to run composer update locally, say 15 times each for 15 projects, then commit all 15, and open pull requests for all 15 etc making the process incredibly slow.
Is there a better way to handle composer update, maybe I need to develop a little CLI application to communicate with the Github api to open PRs and merge them?
What you are describing is exactly what's expected and intended to happen. Full projects with commited lock-files are supposed to install the locked version unless updated.
You could use something like this composer update action to run regularly and create commits when necessary, or work with the GitHub provided Dependabot.
But if this is not coupled with a robust test suite and finely tuned version constraints, you could end up breaking already working projects because some randome dependency introduced an unexpected change in behavior.
I uninstalled the Vercel app from github, but it's still running checks and auto-deployment when I commit code or open a pull request.
How can I remove all the automated checks, environments, and deployments installed by the app? I thought that uninstalling the app would remove automations by default, but I guess that's not true. This is on a private repo.
Your help is appreciated!
Check first if you still see workflows listed with your project.
You might need to delete all their past run results, in order for those to disapear.
In Heroku, connected to Git. I want to deploy my Dev branch, and can select it.
When I manually deploy it does it's thing (deploys my website to Heroku). But my website has Master branch code. I go back to Heroku and it's on Master.
If I select Dev as the branch for either Manual or Automatic, then reload the page, it switches back to Master. Below is a screenshot of me setting the branch to dev. If I do a browser refresh, it resets to Master.
I tried reconnecting Github. Not sure what else it could be.
Deploying Dev was working up until yesterday.
Here is a screenshot of how I manually deploy (as opposed to auto deploy) from the Heroku Deployment tab.
Edit: I should also add, I happily was on Dev, and could deploy Dev updates up until recently. I deployed Master by mistake, bat can't go back to Dev.
I ended up having a corrupt Collection / DB record. I was tipped on another forum that the symptoms I was seeing (Nighscout web app not displaying some data, not the Heroku deploy I was attempting to work around that issue) could be caused by that. So as a last resort I dropped the entire Mongo Collection and I can now deploy Master and Dev, and it sticks in Heroku.
I don't know the significance since the data should be separate from the web app source code itself.
The whole reason I wanted to try Dev was for a fix for parts of the app not working. After initialising the Mongo DB Collection, I can use Master, so Dev (and the fix it contained) is not needed.
I know this isn't the exact root cause, but I'll leave this here in case someone comes across it and hasn't thought to look at the data.
I am starting to delve into Octopus Deploy and setting up my first deployment but I've ran into a bit of a snag. I have tried to be as specific as possible in lieu of finding someone who has experienced this same problem more recently. "This is not a new problem. See -reseach"
The setup
Versions:
TeamCity 10.0.4
Octopus Deploy 3.10.1
My continuous integration stack is comprised of TFS, TeamCity and now Octopus. My deployment process:
TeamCity runs the .NET application build. (Scripts, tests, etc..)
TeamCity Octopus plugin successfully creates the versioned Nuget packages.
A TeamCity build step using "OctopusDeploy: Push packages" pushes the packages to the octopus server.
In Octopus an external feed was added an tested called "Octopus Local Packages" pointing to the default internal octopus package directory: C:\Octopus\Packages.
An octopus project was created with a single step using the "Deploy an IIS Web Site" template, where the package section is setup like this:
The problem
Research
This has happened in the past on versions prior to 3.0.7 where it was fixed. Link to bug thread 1.
Then it started happening again at some point prior to version 3.4.15 where it was fixed. Link to bug thread 2.
Any help, fix, or workaround will be greatly appropriated. If there is a detail that I'm missing I will be more than happy to clarify.
Update
This may very well be a rookie mistake when it comes to Octopus. The error shown in the question is in fact a result of the deployment package not being found. The following are findings through documentation and trial an error:
Octopus Server (built in) is a push feed only. Meaning that packages can be uploaded to this feed but not consumed.
To consume Octopus' server local packages, namely the packages previously pushed to Octopus Server (built in) from say TeamCity, you have to serve those packages yourself.
You can server those packages through Octopus by creating an external feed that points to the server's package default path: C:\Octopus\Packages
Most Importanly, and the fix to the error!
When changes are made to a deployment process step, a new release MUST BE created. Simply redeploying the previous release will try to redeploy with the previous step settings saved in a snapshot and not with the new step settings. This may come a a surprise to TeamCity users like myself based on TeamCity's behaviour.
I have a capistrano task that uses "run_locally" to compass compile/compress my css files and then upload them to the server.
Is it going to be smart and run that on the git branch that's getting deployed, or will it just run on the branch that I currently have in my working copy?
I'd want it to run on the branch that's getting deployed regardless of what I have checked locally. If it's not smart about this would I instead need to run_locally a git checkout on the branch that's getting deployed before running the compile command?
It runs on you current local code. So it matters what code is checked out there. As you mentioned you can try to ensure that you run the version you are going to deploy.
Better would be to do the compilation work on the server.