Some of my Vercel deployments for a project don't work as expected because of previous build cache.
Is there a way to disable using previous build cache by default for deployments for a project?
To skip the Build cache, Use an Environment Variable VERCEL_FORCE_NO_BUILD_CACHE with a value of 1 on your project
Related
I'm doing some early research for a project I plan to deploy to Vercel. I am wondering if the following is possible:
I want to have on GitHub repository. This repository will use environment variables for API tokens, and basic settings.
I have three versions of the project that I want to create. Instead of creating three separate repositories, I'd rather have one repository, and then have the slight differences made using environment variables. This will make updates, fixes, etc much easier.
So, my question is: Is it possible to deploy one repository three times, each with different environment variables, using Vercel?
Yes, possible in deploying multiple environments in 1 repository. This can be done by importing your project to Vercel. For evey commit you made on the git repo, there is a completely new environment created for that. See https://vercel.com/docs/v2/git-integrations
You may also opt to create different git branches for each environment, and Vercel will take care in creating new environment for them. See https://vercel.com/docs/v2/git-integrations/vercel-for-github#a-deployment-for-each-push
With regards to environment variables, here's what the doc says:
The maximum number of Environment Variables per Environment per Project is 100. For example, you can not have more than 100 Production Environment Variables.
Moreover, the total size of Environment Variables applied to a Deployment (including all the Environment Variables Names and Values) is limited to 4kb. Deployments made with Environment Variables exceeding the 4kb limit will fail during the Build Step.
- https://vercel.com/docs/v2/platform/limits?query=environment%20va#environment-variables
Environment Variables: https://vercel.com/docs/v2/build-step#environment-variables
Yes, they give you Production, Preview, and Development environments. Each has their own environment variables you can save via the UI, or you can download the .env via the cli with vercel env pull.
https://vercel.com/docs/build-step#environment-variables
Multiple Vercel projects can be created for the same GitHub repo.
In other words, there is no restriction like only a single Vercel project can be created for the single GitHub repo.
Then, different environment variables can be set for different Vercel projects.
Pushing a commit to the GitHub repo triggers build & deploy of multiple Vercel projects.
Referece: https://github.com/vercel/vercel/discussions/4879#discussioncomment-356114
In my TFS solution, I have two branches Main and Dev. We have four different hosting environments Dev, ITST, QA and Prod, and a different build script for each environment.
Whenever there is a check-in, a build runs and deploys the solution to the Dev environment. However, it is only building our Main branch and not whatever is checked into the Dev branch.
For the Dev build script, how would I go about specifying which branch to build? I've already tried configuring the Source Settings, but when I specified the Dev branch for the Source Control Folder, I kept getting errors related to the mappings.
Update
Here is the error I'm getting: There is no working folder mapping for $/DLS/Application/P1/P1.sln
It sounds like TFS is looking for:
$/DLS/Application/P1/P1.sln
You have it mapped to:
$/DLS/Application/DEV
Try changing the 'Active' mapping to something like:
$/DLS/Application
Or
$/DLS/Application/P1
I have a solution in VS2010 and it has three project, two of these projects have web config file, the projects have web config transformation for each environment (dev, test and prod).
At the process for TFS build option, I have the at the MSBuild Arguments : /p:DeployOnBuild=True
Everything looks good, the drop folder, the zip files and all structure for the final deployment. The issue I am facing the web config for test and prod is not created correctly after the final deployment, I could see at the drop folders the file projectName.SetParameters.xml, it contains the values for development when the build has been QUEUE for Test and Prod. One of the project has the correct web config (test and prod) but the other project has always the dev webconfig.
Is it a bug in the MS Build? What am I missing in the build parameters?
When I create a build deployment package the web config transformation creates the correct web config file, no issues with this process, but I do not want to use build deployment package to deploy my solution.
Any help will be appreciated.
Thank you.
In your Build Definition you probably defined the Configurations to use. Part of that also defines something like Any CPU or x86. As it turns out the solution the Platform "Any CPU" has a space where in the project files the Platform Any CPU does not have a space.
I found the best way to get around this was to leave the Platform blank and only put in the configuration name. VS will pop up a warning letting you know that there is data missing, you can just hit "Yes" to save it anyways. Alternatively you can just type in your configurations like the following |Release,|Debug.
The pattern is [PlatformName]|[ConfigurationName],[PlatformName]|[ConfigurationName],...
My company uses extensive use of ivy to download dependencies. Some of these dependencies are huge (~500MB) and take a while to download from the remote repositories.
To build our application we have an ant script that will first resolve all the dependencies and the deploy to the server.
I have set an "IVY_HOME" environment variable so that all the dependencies are downloaded to D:\ivy_home instead of C:\Users\.ivy2\ - this is because D: is my SSD which is significantly faster, and it is where my local server directories are located - so copying files from ivy_home to the server is super fast.
But for some reason when I am using IvyDE plugin inside eclipse - it always wants to download a separate copy of all the dependencies and puts them into my C:\ which is causing several issues:
Local publishes from the ant script will not be picked up in eclipse since they are placed into a different location
Dependencies already downloaded in D: will not get picked up which makes the ivy Resolve inside eclipse much slower than it needs to be
The dependencies are in a slower drive in eclipse so performing searches, and executing these jars is also slower
How about creating symlink to replace the .ivy2 in Users to D? I've tried it on my own and it's looks working fine.
Open cmd as root, and then execute this line
mklink /d C:\Users\{username}\.ivy2 D:\.ivy2
I'd create an ivysettings.xml file and specify the location of my cache using the caches directive. See the following answer for example:
can I turn off the .ivy cache all together?
Why don't you set up IVY globally with the ivysettings.xml along with a property file.
This property file could have this:
ivy.default.ivy.user.dir=D:\ivy_home
For individual projects you could uncheck "enable project specific settings" for each IvyDE library management, so they would use IVY global settings, with one extra eclipse environment configuration.
We recently switched from Ant to Buildr for building our projects. We use Ivy for dependency management, using the ivy4r Buildr extension. We have a local repository at the office which is used as a cache for public artifacts and in which we also publish our own artifacts.
Now for the problem: I'd like to be able to build my project when I do not have access to the office repository. Buildr has a flag to tell it to work offline (-o), but ivy4r does not seem to take this into account. Is there any way to make Ivy not try to download artifacts? I have them all available in the cache on my machine already.
Setting the cache timeout to eternal
You can set the cache property ${ivy.cache.ttl.default} to eternal this will set the TTL: so that the repository will not be checked for new revisions.
You could achieve this by calling ant with the following parameter:
ant -Divy.cache.ttl.default=eternal build
This is from the documentation:
Defines a TTL (Time To Live) rule for resolved revision caching. When
Ivy resolves a dynamic version constraint (like latest.integration or
a version range), it can store the result of the resolution (like
latest.integration=1.5.1) for a given time, called TTL. It means that
Ivy will reuse this dynamic revision resolution result without
accessing the repositories for the duration of the TTL, unless running
resolve in refresh mode.
...
The TTL duration can also be set to 'eternal', in which case once
resolved the revision is always use, except when resolving in refresh
mode.
Other references:
IVY-879 Implementation of this feature
Setting UseCacheOnly for the resolve task
The resolve task has the attribute useCacheOnly, which can be used to
force[s] the resolvers to only use their caches and not their actual
contents
Example:
<ivy:resolve file="path/to/ivy.xml" useCacheOnly="true/>