I'm playing with the UI5 minifying and uglifying. As far as I know, there are two common approaches:
Grunt task with gruntfile.cjs, based on grunt-openui5.
UI5 Tooling with ui5.yaml, based on #ui5/cli.
My ui5.yaml:
specVersion: "2.5"
type: application
metadata:
name: com.myapp
framework:
name: OpenUI5
version: 1.95.0
resources:
configuration:
paths:
webapp: src/webapp
builder:
cachebuster:
signatureType: hash
componentPreload:
namespaces:
- "com/myapp"
paths:
- "src/webapp"
To run the minifying with #ui5/cli, I execute the following NPM-Script task: "test": "ui5 build preload", as the result, I get a brand new dist folder with minified and debug-friendly files (e.g. App.controller.js and App-dbg.controller.js), in addition, Component-preload.js is generated as well.
My questions:
Is Grunt-based approach a legacy, while #ui5/cli is standard approach nowadays?
Is it possible to get a minified version of the UI5 app (just a Component-preload.js) with #ui5/cli without a dist folder?
Related
I have a flutter package flutter_opencc_ffi_web, which contains some JS files. This package is transitively included in another project of mine. When I build a non-web bundle, I'd like to exclude the JS assets(about 1Mb). How can I achieve that?
I've tried the build_config, but don't know how to exclude package assets. The following config doesn't work.
build.yaml
targets:
$default:
sources:
exclude:
- assets/opencc/**
- assets/packages/flutter_opencc_ffi_web/assets/opencc/**
dependencies:
flutter_opencc_ffi_web:
exclude:
- assets/opencc/**
Here is my idea: build a static web page template, over time add .md files to a /posts directory and build a CI job to convert the .md files to html (with the showdownjs/showdown package).
Is there a need to install the package on every push? Seems like a waste, but uploading /node-modules is incorrect as well. Is there a way to install the package once, and let github action just work with it (run the md to html converter on newly added files)?
You have 2 options:
Recommened: Use caching action to cache dependencies for your project - using a hash from package-lock.json as a key to make sure it rebuild when depenendencies has changed:
- name: Cache node modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ hashFiles('**/package-lock.json') }}
- name: Install Dependencies
run: npm install
Push your node_modules to Git repository so it's checkout together with everything else
For optimising a need to run your converted you can use this action:
https://github.com/tj-actions/changed-files/
and detect if any files were modified at certain path
Playing with UI5 Tooling, I see that the ui5.yaml config file contains a framework library section, where we supposed to specify UI5 app dependencies, e.g. sap.m, sap.ui.core etc.:
specVersion: "2.5"
type: application
metadata:
name: com.myApp
framework:
name: OpenUI5
version: 1.95.0
libraries:
- name: sap.m
- name: sap.ui.core
If I understand it correctly, these libraries section is used to incorporate these libs into Component-preload.js. Is it a correct assumption?
My questions:
Should the framework/libraries section of ui5.yaml be identical to the sap.ui5/dependencies/libs one of manifest.json?
Should I specify this libraries section at all in case, if I consume UI5 lib from the CDN?
I am trying to make my first gitlab ci pipeline with sbt.
i am trying to make build and test stages.
the problem is that although i compile the project at build, it compiles again at test stage before running the tests.
can someone help me to understand why this is happening and how to solve it?
sbt version: 1.2.7
this is my gitlab-ci.yml file:
image: docker-registry:5000/sbt-docker:latest
variables:
SBT_OPTS: "-Dsbt.global.base=sbt-cache/sbtboot -Dsbt.boot.directory=sbt-cache/boot -Dsbt.ivy.home=sbt-cache/ivy Dsbt.coursier.home=sbt-cache/coursier -Dsbt.io.jdktimestamps=true"
COURSIER_CACHE: sbt-cache/coursier
stages:
- build
- test
cache:
paths:
- "sbt-cache/ivy/cache"
- "sbt-cache/boot"
- "sbt-cache/sbtboot"
- "sbt-cache/coursier"
build:
stage: build
script:
- sbt -J-Xmx2G clean core/compile core/package
artifacts:
untracked: true
paths:
- "target/"
test:
stage: test
dependencies:
- build
script:
- sbt core/test
allow_failure: true
You need to cache the target/ folders of your project. I'm not familiar with CircleCI, it seems that there is a cache:paths key available, which sounds nice as long as the cache is per branch.
I'm using helm charts to deploy around 15 microservices. There is a parent helm chart with requirements.yaml where the all the required microservices are listed as dependencies.
Sample requirements.yaml file:
dependencies:
- name: service1
repository: "#stable"
version: <version>
- name: service2
repository: "#stable"
version: <version>
- name: service3
repository: "#stable"
version: <version>
- name: service4
repository: "#stable"
version: <version>
condition: false
When I run helm dependency update all the charts that are listed as dependency are downloaded. There are scenarios where few services are under development and are not required to be deployed in production.
We have different artifactory for prod and non-prod environment and the disabled services are not in prod artifactory. Hence it gives an error saying helm chart missing. I understand that the condition flag doesn't install the dependency but how can I stop it from downloading the dependency ?
It might come a bit late, but I sorted out a similar problem recently and I thought it might help others to share. You can use the condition key when declaring dependencies in your Chart.yaml:
dependencies:
- condition: gitea.cache.builtIn.enabled
name: memcached
repository: https://charts.bitnami.com/bitnami
version: 4.2.20
With the bit in values.yaml being as follows:
[...]
gitea:
cache:
builtIn:
enabled: true
[...]
This example is extracted from the fantastic gitea helm chart repo and should be self explanatory. However, you can take a look at Helm documentation
Be aware that if there are nested charts more than 2 levels deep, helm2 might misbehave so I recommend you to take a look at Helm3 for that.
Finally please note that in my case (as I'm following a small detour when deploying Helm charts, the check for the condition happens when rendering the helm chart not when running helm dependency update