At present we're migrating our build infrastructure from expo with turtle to use EAS local builds. One of the issues we had with turtle is the need for setting up an external web host or use expo publish before you run turtle.
Does EAS local build still require the expo publish? step before calling the eas build --local?
Related
I am going to convert current expo project from Expo managed workflow to bare React Native to use react-native-branch.
I run this command on terminal.
expo eject
I can run app on local environment, but debug and release apk is not working.
Is it possible to build web version using eas-cli build command? I'm using eas.json file to manage different environment configurations, and I'm using iOS, Android & web versions, but for the moment I keep building the web using expo build, so the environments are always the same...
How can I manage the eas build for web?
I get this error when i use this line:
eas build -p android
I am trying to build the project but it gives this error:
Error: Cannot copy 'C:\Users\xx' to a subdirectory of itself,
'C:\Users\xx\AppData\Local\Temp\eas-cli-nodejs\5897d1cd-52ae-4c3c-a5c4-577
69487c9f8-shallow-clone'
This answer may be late but I came across this in assisting a fellow dev and think I can answer this for other devs in the future at least.
So, EAS has integration capabilities with git. What that means is that for instance, when running a build command, EAS uploads a shallow clone of your repository to EAS Build. This error will come up when you do not have git setup on your machine or your project has not remote base that you're working off of.
There is a solution to disable the git integration ability for your project if you so wish. That is setting the environment variable EAS_NO_VCS=1 So when running your build command, do this instead:
Mac: EAS_NO_VCS=1 eas <command>
Windows: npx cross-env EAS_NO_VCS=1 eas <command>
Reference: https://github.com/expo/fyi/blob/main/eas-vcs-workflow.md
Hope this helps.
currently our process works, but it takes too much time due that the fronend Ember app needs to be build into every single environment we have ( 5 environments ). because we never know which environment will be available when we release it.
we intend to add even more environments because every developer should have his own working development environment. (because of the backend)
how we do it, is that we create a frontend build and a backend build which creates artifacts.
now the frontent build takes around 2 minutes for every environment.
ember build --env=test and ember build --env=acceptance and ember build --env=development ... and more
when the artifacts are created we then create the release picking the correct ones depending on which environment we release (this done via release pipeline).
my question is can we make a frontend ember build somehow not depending on the environment?
i would like to note that we are using azure service fabric.
I don't think there is anyway around multiple Ember builds because each one will be different (i.e. production vs. development).
You can batch together each build inside one CI build/build task and produce artifact(s) to be used in your release pipeline.
Run the following command once for each environment you have (assuming you are using Ember-CLI) sequentially in one build task.
ember build --environment={{YOUR-ENV-HERE}} --output-path="dist/{{YOUR-ENV-HERE}}/"
You can then either upload the entire dist/ folder as an artifact and scope each environment in your release pipeline to the corresponding artifact subdirectory, or you can upload each folder inside /dist as an individual artifact and scope each environment in your release pipeline to its corresponding artifact.
only the configuration it changes. basically the api endpoints
We're using the hosted build agent on VSTS to build and release our ASP.NET Core code to Azure App service.
My question is: can we run WebPack to handle front-end tasks on this hosted build on VSTS or do we have to do it manually before checking the code into our repository?
Update:
I'm utilizing the new ASP.NET Core Build (Preview) template that's available on VSTS -- see below:
Here are the steps -- out of the box:
For VSTS we're working on an extension, currently it's in beta phase, you can ask for a share.
Check the VSTS marketplace.
Check this github repo.
Webpack is definitively not a first class citizen for VS2015 and VSTS. Streamlining webpack for CI/CD has been a real headache in my case, especially as webpack was introduced hastily to solve dreadful performance issues with a large monolithic SPA (ASP.NET 4.6, Kendo, 15,000 files, 2000 folders). To cut short, after trying many scenarios to make sure that freshly rebuilt bundles would end up in IIS and Azure webapp, I did a 2-pass build. The sequence of VSTS tasks is as follows: npm install global, npm install local, npm webpack install local, npm webpack install global, build pass 1, webpack, build pass 2, etc... This works with hosted and private agents, providing you supply the proper path for webpack as webpack is installed in a different location in host and in private (did not find a way to chose the webpack install location for consistency). I scorch everything before starting the build. Also need to do these in VS2015 solution : (1) unload "built" folder, and (2) Add Content Include="Built\StarStar" in project file. The "built" folder contains the bundles and should appear greyed, otherwise more bad surprises and instabilities to deal with...
Build-Pass #2 task in VSTS BUILD allows to collect the fresh bundles generated by Build-Pass #1 and includes them automatically in the package to be published.
Without a second build-pass, collecting the bundles and merging them in the zip package is a nightmare, especially when you have 15,000 files to unzip then rezip (300 ms per file!!). Did not find file-merging capability that I could readily use in VSTS.
I have my hears to the ground listening for someone coming up with a more efficient CI/CD scheme for webpack. In the meanwhile, my 2-pass-build workaround is working flawlessly, but slow indeed.
I anticipate that the advances with ASP.NET core, Angular 2 and webpack will look into solving this elegantly.