@eui/eds 21.3.4-snapshot-1783677674979
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/classes/EdsChipModel.html +606 -0
- package/docs/classes/EuiChipTooltip.html +425 -0
- package/docs/components/EdsBadge.html +810 -0
- package/docs/components/EdsButton.html +793 -0
- package/docs/components/EdsChip.html +911 -0
- package/docs/components/EdsIcon.html +675 -0
- package/docs/components/EdsIconImage.html +604 -0
- package/docs/directives/EuiBaseColorVariantsDirective.html +1165 -0
- package/docs/directives/EuiBaseSizeVariantsDirective.html +1402 -0
- package/docs/fonts/ionicons.eot +0 -0
- package/docs/fonts/ionicons.svg +2090 -0
- package/docs/fonts/ionicons.ttf +0 -0
- package/docs/fonts/ionicons.woff +0 -0
- package/docs/fonts/ionicons.woff2 +0 -0
- package/docs/fonts/roboto-v15-latin-300.eot +0 -0
- package/docs/fonts/roboto-v15-latin-300.svg +314 -0
- package/docs/fonts/roboto-v15-latin-300.ttf +0 -0
- package/docs/fonts/roboto-v15-latin-300.woff +0 -0
- package/docs/fonts/roboto-v15-latin-300.woff2 +0 -0
- package/docs/fonts/roboto-v15-latin-700.eot +0 -0
- package/docs/fonts/roboto-v15-latin-700.svg +310 -0
- package/docs/fonts/roboto-v15-latin-700.ttf +0 -0
- package/docs/fonts/roboto-v15-latin-700.woff +0 -0
- package/docs/fonts/roboto-v15-latin-700.woff2 +0 -0
- package/docs/fonts/roboto-v15-latin-italic.eot +0 -0
- package/docs/fonts/roboto-v15-latin-italic.svg +323 -0
- package/docs/fonts/roboto-v15-latin-italic.ttf +0 -0
- package/docs/fonts/roboto-v15-latin-italic.woff +0 -0
- package/docs/fonts/roboto-v15-latin-italic.woff2 +0 -0
- package/docs/fonts/roboto-v15-latin-regular.eot +0 -0
- package/docs/fonts/roboto-v15-latin-regular.svg +308 -0
- package/docs/fonts/roboto-v15-latin-regular.ttf +0 -0
- package/docs/fonts/roboto-v15-latin-regular.woff +0 -0
- package/docs/fonts/roboto-v15-latin-regular.woff2 +0 -0
- package/docs/images/compodoc-vectorise-inverted.png +0 -0
- package/docs/images/compodoc-vectorise-inverted.svg +201 -0
- package/docs/images/compodoc-vectorise.png +0 -0
- package/docs/images/compodoc-vectorise.svg +201 -0
- package/docs/images/favicon.ico +0 -0
- package/docs/index.html +2264 -0
- package/docs/js/compodoc.js +14 -0
- package/docs/js/lazy-load-graphs.js +44 -0
- package/docs/js/libs/EventDispatcher.js +5 -0
- package/docs/js/libs/bootstrap-native.js +2 -0
- package/docs/js/libs/clipboard.min.js +7 -0
- package/docs/js/libs/custom-elements-es5-adapter.js +15 -0
- package/docs/js/libs/custom-elements.min.js +38 -0
- package/docs/js/libs/d3.v3.min.js +2 -0
- package/docs/js/libs/deep-iterator.js +2 -0
- package/docs/js/libs/es6-shim.min.js +12 -0
- package/docs/js/libs/htmlparser.js +23 -0
- package/docs/js/libs/innersvg.js +9 -0
- package/docs/js/libs/jszip.min.js +13 -0
- package/docs/js/libs/lit-html.js +1 -0
- package/docs/js/libs/prism.js +46 -0
- package/docs/js/libs/promise.min.js +6 -0
- package/docs/js/libs/svg-pan-zoom.min.js +3 -0
- package/docs/js/libs/tablesort.min.js +6 -0
- package/docs/js/libs/tablesort.number.min.js +6 -0
- package/docs/js/libs/vis-network.min.js +78 -0
- package/docs/js/libs/zepto.min.js +2 -0
- package/docs/js/menu-wc.js +119 -0
- package/docs/js/menu-wc_es5.js +40 -0
- package/docs/js/menu.js +269 -0
- package/docs/js/routes/routes_index.js +1 -0
- package/docs/js/routes.js +308 -0
- package/docs/js/search/lunr.min.js +6 -0
- package/docs/js/search/search-lunr.js +65 -0
- package/docs/js/search/search.js +273 -0
- package/docs/js/search/search_index.js +4 -0
- package/docs/js/sourceCode.js +58 -0
- package/docs/js/svg-pan-zoom.controls.js +53 -0
- package/docs/js/tabs.js +21 -0
- package/docs/js/tree.js +147 -0
- package/docs/json/EdsBadge.md +28 -0
- package/docs/json/EdsButton.md +31 -0
- package/docs/json/EdsChip.md +30 -0
- package/docs/json/EdsIcon.md +32 -0
- package/docs/json/EdsIconImage.md +13 -0
- package/docs/json/EuiBaseColorVariantsDirective.md +20 -0
- package/docs/json/EuiBaseSizeVariantsDirective.md +23 -0
- package/docs/json/HbsRenderService.md +6 -0
- package/docs/json/TemplateEditorService.md +6 -0
- package/docs/json/TemplatePlaygroundComponent.md +8 -0
- package/docs/json/ZipExportService.md +6 -0
- package/docs/json/documentation.json +5209 -0
- package/docs/miscellaneous/variables.html +415 -0
- package/docs/modules.html +201 -0
- package/docs/overview.html +236 -0
- package/docs/routes.html +204 -0
- package/docs/styles/bootstrap-card.css +219 -0
- package/docs/styles/bootstrap.min.css +6 -0
- package/docs/styles/compodoc.css +1124 -0
- package/docs/styles/dark.css +121 -0
- package/docs/styles/ionicons.min.css +11 -0
- package/docs/styles/laravel.css +113 -0
- package/docs/styles/material.css +131 -0
- package/docs/styles/original.css +51 -0
- package/docs/styles/postmark.css +238 -0
- package/docs/styles/prism.css +301 -0
- package/docs/styles/readthedocs.css +117 -0
- package/docs/styles/reset.css +129 -0
- package/docs/styles/stripe.css +106 -0
- package/docs/styles/style.css +7 -0
- package/docs/styles/tablesort.css +33 -0
- package/docs/styles/vagrant.css +130 -0
- package/docs/template-playground/default-templates.json +192 -0
- package/docs/template-playground/hbs-render.service.ts +212 -0
- package/docs/template-playground/main.ts +9 -0
- package/docs/template-playground/template-editor.service.ts +173 -0
- package/docs/template-playground/template-playground.component.ts +614 -0
- package/docs/template-playground/template-playground.module.ts +29 -0
- package/docs/template-playground/zip-export.service.ts +86 -0
- package/docs/template-playground-app/app.js +1389 -0
- package/docs/template-playground-app/index.html +462 -0
- package/fesm2022/eui-eds-eds-badge.mjs +175 -0
- package/fesm2022/eui-eds-eds-badge.mjs.map +1 -0
- package/fesm2022/eui-eds-eds-button.mjs +169 -0
- package/fesm2022/eui-eds-eds-button.mjs.map +1 -0
- package/fesm2022/eui-eds-eds-chip.mjs +196 -0
- package/fesm2022/eui-eds-eds-chip.mjs.map +1 -0
- package/fesm2022/eui-eds-eds-icon-image.mjs +65 -0
- package/fesm2022/eui-eds-eds-icon-image.mjs.map +1 -0
- package/fesm2022/eui-eds-eds-icon.mjs +136 -0
- package/fesm2022/eui-eds-eds-icon.mjs.map +1 -0
- package/fesm2022/eui-eds-shared.mjs +322 -0
- package/fesm2022/eui-eds-shared.mjs.map +1 -0
- package/fesm2022/eui-eds.mjs +6 -0
- package/fesm2022/eui-eds.mjs.map +1 -0
- package/package.json +72 -0
- package/types/eui-eds-eds-badge.d.ts +74 -0
- package/types/eui-eds-eds-badge.d.ts.map +1 -0
- package/types/eui-eds-eds-button.d.ts +75 -0
- package/types/eui-eds-eds-button.d.ts.map +1 -0
- package/types/eui-eds-eds-chip.d.ts +105 -0
- package/types/eui-eds-eds-chip.d.ts.map +1 -0
- package/types/eui-eds-eds-icon-image.d.ts +34 -0
- package/types/eui-eds-eds-icon-image.d.ts.map +1 -0
- package/types/eui-eds-eds-icon.d.ts +50 -0
- package/types/eui-eds-eds-icon.d.ts.map +1 -0
- package/types/eui-eds-shared.d.ts +86 -0
- package/types/eui-eds-shared.d.ts.map +1 -0
- package/types/eui-eds.d.ts +3 -0
- package/types/eui-eds.d.ts.map +1 -0
package/docs/index.html
ADDED
|
@@ -0,0 +1,2264 @@
|
|
|
1
|
+
<!doctype html>
|
|
2
|
+
<html class="no-js" lang="">
|
|
3
|
+
<head>
|
|
4
|
+
<meta charset="utf-8">
|
|
5
|
+
<meta http-equiv="x-ua-compatible" content="ie=edge">
|
|
6
|
+
<title>Application documentation</title>
|
|
7
|
+
<meta name="description" content="">
|
|
8
|
+
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
9
|
+
|
|
10
|
+
<link rel="icon" type="image/x-icon" href="./images/favicon.ico">
|
|
11
|
+
<link rel="stylesheet" href="./styles/style.css">
|
|
12
|
+
<link rel="stylesheet" href="./styles/dark.css">
|
|
13
|
+
<link rel="stylesheet" href="./styles/material.css">
|
|
14
|
+
</head>
|
|
15
|
+
<body>
|
|
16
|
+
<script>
|
|
17
|
+
// Blocking script to avoid flickering dark mode
|
|
18
|
+
// Dark mode toggle button
|
|
19
|
+
var useDark = window.matchMedia('(prefers-color-scheme: dark)');
|
|
20
|
+
var darkModeState = useDark.matches;
|
|
21
|
+
var $darkModeToggleSwitchers = document.querySelectorAll('.dark-mode-switch input');
|
|
22
|
+
var $darkModeToggles = document.querySelectorAll('.dark-mode-switch');
|
|
23
|
+
var darkModeStateLocal = localStorage.getItem('compodoc_darkmode-state');
|
|
24
|
+
|
|
25
|
+
function checkToggle(check) {
|
|
26
|
+
for (var i = 0; i < $darkModeToggleSwitchers.length; i++) {
|
|
27
|
+
$darkModeToggleSwitchers[i].checked = check;
|
|
28
|
+
}
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
function toggleDarkMode(state) {
|
|
32
|
+
if (window.localStorage) {
|
|
33
|
+
localStorage.setItem('compodoc_darkmode-state', state);
|
|
34
|
+
}
|
|
35
|
+
|
|
36
|
+
checkToggle(state);
|
|
37
|
+
|
|
38
|
+
const hasClass = document.body.classList.contains('dark');
|
|
39
|
+
|
|
40
|
+
if (state) {
|
|
41
|
+
for (var i = 0; i < $darkModeToggles.length; i++) {
|
|
42
|
+
$darkModeToggles[i].classList.add('dark');
|
|
43
|
+
}
|
|
44
|
+
if (!hasClass) {
|
|
45
|
+
document.body.classList.add('dark');
|
|
46
|
+
}
|
|
47
|
+
} else {
|
|
48
|
+
for (var i = 0; i < $darkModeToggles.length; i++) {
|
|
49
|
+
$darkModeToggles[i].classList.remove('dark');
|
|
50
|
+
}
|
|
51
|
+
if (hasClass) {
|
|
52
|
+
document.body.classList.remove('dark');
|
|
53
|
+
}
|
|
54
|
+
}
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
useDark.addEventListener('change', function (evt) {
|
|
58
|
+
toggleDarkMode(evt.matches);
|
|
59
|
+
});
|
|
60
|
+
if (darkModeStateLocal) {
|
|
61
|
+
darkModeState = darkModeStateLocal === 'true';
|
|
62
|
+
}
|
|
63
|
+
toggleDarkMode(darkModeState);
|
|
64
|
+
</script>
|
|
65
|
+
<script>
|
|
66
|
+
// --- Iframe navigation tracking for Template Playground ---
|
|
67
|
+
function sendCurrentUrlToParent() {
|
|
68
|
+
if (window.parent && window.parent !== window) {
|
|
69
|
+
window.parent.postMessage({
|
|
70
|
+
type: 'compodoc-iframe-navigate',
|
|
71
|
+
url: window.location.pathname + window.location.hash
|
|
72
|
+
}, '*');
|
|
73
|
+
}
|
|
74
|
+
}
|
|
75
|
+
window.addEventListener('hashchange', sendCurrentUrlToParent, false);
|
|
76
|
+
window.addEventListener('popstate', sendCurrentUrlToParent, false);
|
|
77
|
+
window.addEventListener('DOMContentLoaded', sendCurrentUrlToParent, false);
|
|
78
|
+
</script>
|
|
79
|
+
|
|
80
|
+
<div class="navbar navbar-default navbar-fixed-top d-md-none p-0">
|
|
81
|
+
<div class="d-flex">
|
|
82
|
+
<a href="./" class="navbar-brand">Application documentation</a>
|
|
83
|
+
<button type="button" class="btn btn-default btn-menu ion-ios-menu" id="btn-menu"></button>
|
|
84
|
+
</div>
|
|
85
|
+
</div>
|
|
86
|
+
|
|
87
|
+
<div class="xs-menu menu" id="mobile-menu">
|
|
88
|
+
<div id="book-search-input" role="search"><input type="text" placeholder="Type to search"></div> <compodoc-menu></compodoc-menu>
|
|
89
|
+
</div>
|
|
90
|
+
|
|
91
|
+
<div class="container-fluid main">
|
|
92
|
+
<div class="row main">
|
|
93
|
+
<div class="d-none d-md-block menu">
|
|
94
|
+
<compodoc-menu mode="normal"></compodoc-menu>
|
|
95
|
+
</div>
|
|
96
|
+
<!-- START CONTENT -->
|
|
97
|
+
<div class="content readme">
|
|
98
|
+
<div class="content-data">
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
<h1>CSDR documentation</h1>
|
|
102
|
+
<h2>Table of Contents</h2>
|
|
103
|
+
<ul>
|
|
104
|
+
<li><a href="#what-is-csdr">What is CSDR?</a></li>
|
|
105
|
+
<li><a href="#csdr-engine-overview">CSDR Engine Overview</a><ul>
|
|
106
|
+
<li><a href="#micro-frontend-architecture">Micro-Frontend Architecture</a></li>
|
|
107
|
+
<li><a href="#baep-portal-architecture">BAEP Portal Architecture</a></li>
|
|
108
|
+
<li><a href="#reference-links">Reference Links</a></li>
|
|
109
|
+
</ul>
|
|
110
|
+
</li>
|
|
111
|
+
<li><a href="#getting-started">Getting Started</a><ul>
|
|
112
|
+
<li><a href="#requesting-a-new-repository">Requesting a New Repository</a></li>
|
|
113
|
+
<li><a href="#prerequisites">Prerequisites</a></li>
|
|
114
|
+
<li><a href="#installation">Installation</a></li>
|
|
115
|
+
<li><a href="#how-local-setup-works">How Local Setup Works</a></li>
|
|
116
|
+
<li><a href="#setting-up-a-baep-portal-locally">Setting Up a BAEP Portal Locally</a></li>
|
|
117
|
+
<li><a href="#running-the-portal-locally">Running the Portal Locally</a></li>
|
|
118
|
+
<li><a href="#setting-up-myworkplace-locally">Setting Up MyWorkplace Locally</a></li>
|
|
119
|
+
<li><a href="#running-myworkplace-with-mock-server">Running MyWorkplace with Mock Server</a></li>
|
|
120
|
+
<li><a href="#running-myworkplace-with-remote-api-proxy">Running MyWorkplace with Remote API Proxy</a></li>
|
|
121
|
+
</ul>
|
|
122
|
+
</li>
|
|
123
|
+
<li><a href="#project-structure">Project Structure</a><ul>
|
|
124
|
+
<li><a href="#portal-host-directory-layout">Portal Host Directory Layout</a></li>
|
|
125
|
+
<li><a href="#ui-package-structure">UI Package Structure</a></li>
|
|
126
|
+
</ul>
|
|
127
|
+
</li>
|
|
128
|
+
<li><a href="#configuration-repository">Configuration Repository</a></li>
|
|
129
|
+
<li><a href="#portal-host-repository">Portal Host Repository</a><ul>
|
|
130
|
+
<li><a href="#host-source-injection-and-virtual-host-generation">Host Source Injection and Virtual Host Generation</a></li>
|
|
131
|
+
<li><a href="#routes-definitions">Routes Definitions</a></li>
|
|
132
|
+
<li><a href="#workspaces-definitions-available-for-myworkplace">Workspaces Definitions</a></li>
|
|
133
|
+
</ul>
|
|
134
|
+
</li>
|
|
135
|
+
<li><a href="#developing-your-micro-frontend">Developing your micro-frontend</a></li>
|
|
136
|
+
<li><a href="#releasing-your-micro-frontend">Releasing your micro-frontned</a></li>
|
|
137
|
+
<li><a href="#csdr-git-branching">CSDR git branching</a></li>
|
|
138
|
+
<li><a href="#mock-server-and-api-integration">Mock Server and API Integration</a></li>
|
|
139
|
+
<li><a href="#annex--package-and-remote-migration-to-a-next-eui-version---v19-to-v21-is-presented-here-032026">ANNEX : v21 migration</a></li>
|
|
140
|
+
<li><a href="#annex--csdr-commands">ANNEX : CSDR commands</a></li>
|
|
141
|
+
<li><a href="#annex--conventional-commit-message-format">ANNEX : Conventional commit message format</a></li>
|
|
142
|
+
</ul>
|
|
143
|
+
<h2>What is CSDR?</h2>
|
|
144
|
+
<p>CSDR stands for: Common Shared Developers Repositories, it has been setup for MyWorkplace and Compass Corporate in the first place to enforce : reusability, visibility, conventions and use of a common pipeline / default local tools for development of large-scale application and micro-frontend architecture like MyWorkplace and F&T portal.</p>
|
|
145
|
+
<h2>CSDR Engine Overview</h2>
|
|
146
|
+
<p>The CSDR Engine provides a set of tools in order to support the BAEP (Business Agnostic External Portal) projects, MyWorkplace and other applications for local development
|
|
147
|
+
and the Gitlab Corporate CI pipeline execution.</p>
|
|
148
|
+
<p>It supports eUI Angular libraries package pipelines (audit / lint / test / build and publication) together with the micro-frontend architecture with hosts and remotes pipelines scripts that can be both executed locally and on gitlab CI pipeline side.</p>
|
|
149
|
+
<h3>Micro-Frontend Architecture</h3>
|
|
150
|
+
<ul>
|
|
151
|
+
<li>Scale large-scale UI development, benefits from years of experience in MyWorkplace / F&T portal</li>
|
|
152
|
+
<li>Isolate « business domains » through independent release cycles and responsibilities of delivery</li>
|
|
153
|
+
<li>Concept of « host / shell » AND « remotes / sections » loaded dynamically at runtime.</li>
|
|
154
|
+
<li>Ease the migration for the UI teams which can progress at their pace – multiple eUI versions used by different remotes within the same host application.</li>
|
|
155
|
+
<li>Central CSDR pipelines with DevOps engine used locally (playground) and on gitlab pipelines, ensuring local developer’s experience / gitlab corporate pipeline integration centrally maintained by eUI/MyWorkplace team.</li>
|
|
156
|
+
<li>Remote as « micro-frontend » having their own set of dependencies / eUI angular libraries they’re depending on, without affecting others.</li>
|
|
157
|
+
<li>Targeted environments per remote « à la carte » allowing each teams to deliver their own dependencies without affecting others within the same remote delivery</li>
|
|
158
|
+
<li>Core team supporting the architecture : training / support and pipeline, remote and UI library setup</li>
|
|
159
|
+
</ul>
|
|
160
|
+
<h4>Why Micro-Frontends?</h4>
|
|
161
|
+
<p>For big enterprise applications, there is often the request of improving their scalability by fulfilling the following requests:</p>
|
|
162
|
+
<ul>
|
|
163
|
+
<li>Allowing the release of some parts independently from the rest,</li>
|
|
164
|
+
<li>Improving the isolation of relevant parts in order to better manage their deps (main libs included).</li>
|
|
165
|
+
</ul>
|
|
166
|
+
<p>Both requests can often be grouped under the concept of micro frontends. Following a simple Google search, the definition of a micro frontend architecture is more or less the following:</p>
|
|
167
|
+
<p>A Micro-frontend architecture is a design approach in which a front-end app is decomposed into individual, semi-independent “microapps” working loosely together. The micro-frontend concept is vaguely inspired by, and named after, microservices.</p>
|
|
168
|
+
<p>The motivation behind this architecture can be shortly justified like this:</p>
|
|
169
|
+
<ul>
|
|
170
|
+
<li>Mid to large scale applications,</li>
|
|
171
|
+
<li>Multiple teams,</li>
|
|
172
|
+
<li>Separate application “parts”,</li>
|
|
173
|
+
<li>Multiple “parts” sharing libraries.</li>
|
|
174
|
+
<li>Although micro frontends have been getting a lot of attention lately, as of yet there is no single dominant implementation and no clear “best” micro-frontend framework. In fact, there is a variety of approaches depending on the objectives and requirements.</li>
|
|
175
|
+
</ul>
|
|
176
|
+
<h3>BAEP Portal Architecture</h3>
|
|
177
|
+
<p>BAEP stands for : Business Agnostic External Portal, based on CSDR micro-frontend architecture, it is a set of tools and reusable services for team to get up to speed developing their own portal both from the UI perspective (what CSDR micro-frontend offers) and also the reusability of common services and recipes from F&T itself (IAM, PNS, etc...) targeted to External users.</p>
|
|
178
|
+
<h3>Reference Links</h3>
|
|
179
|
+
<p>For CSDR : <a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/spaces/MWP/pages/1324480994/UI+development">https://citnet.tech.ec.europa.eu/CITnet/confluence/spaces/MWP/pages/1324480994/UI+development</a>
|
|
180
|
+
For MyWorkplace : <a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/spaces/MWP/pages/1233067794/01+-+MyWorkplace+features">https://citnet.tech.ec.europa.eu/CITnet/confluence/spaces/MWP/pages/1233067794/01+-+MyWorkplace+features</a></p>
|
|
181
|
+
<hr>
|
|
182
|
+
<hr>
|
|
183
|
+
<h2>Getting started</h2>
|
|
184
|
+
<h3>Requesting a New Repository</h3>
|
|
185
|
+
<p>The first step once you need a UI package to work with on an existing portal / MyWorkplace or the creation of a new portal (BAEP) from scratch (following a introductory meeting that needs to be conducted by the BAEP DIGIT.A.2 / A.4 colleagues), you need to contact DIGIT.A.4 MyWorkplace team which will support the creation of the necessary repository to host your UI package/remotes/host portal (<a href="mailto:DIGIT-EUI-SUPPORT@ec.europa.eu">DIGIT-EUI-SUPPORT@ec.europa.eu</a>).</p>
|
|
186
|
+
<p>Some information to specify on your request :</p>
|
|
187
|
+
<ul>
|
|
188
|
+
<li>name : should be in the format : <business-domain>-<business-package> : by default a "remote" will be created,</li>
|
|
189
|
+
<li>section or participant : ex : cc-task-actions resulting in repository creation : cc-task-actions-remote-eui21 AND cc-task-actions-ui repository</li>
|
|
190
|
+
</ul>
|
|
191
|
+
<p>For portals creation / BAEP, please contact DIGIT.A.4 / MWP team directly.</p>
|
|
192
|
+
<h3>Prerequisites</h3>
|
|
193
|
+
<h4>Gitlab corporate access</h4>
|
|
194
|
+
<p>Create your Personal Access Token here : <a href="https://sdlc.webcloud.ec.europa.eu/-/user_settings/personal_access_tokens">https://sdlc.webcloud.ec.europa.eu/-/user_settings/personal_access_tokens</a></p>
|
|
195
|
+
<h4>Local tools installation</h4>
|
|
196
|
+
<ul>
|
|
197
|
+
<li>NodeJS >= 22.6.0 / install nvm for easy switch between node versions</li>
|
|
198
|
+
<li>Git client</li>
|
|
199
|
+
<li>Yarn installed globally</li>
|
|
200
|
+
<li>Login to CSDR Nexus registry (see step 2b here : <a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/display/MWP/00+-+pre-requisites">https://citnet.tech.ec.europa.eu/CITnet/confluence/display/MWP/00+-+pre-requisites</a>)</li>
|
|
201
|
+
</ul>
|
|
202
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm adduser --registry=https://csdr-nexus.devops.tech.ec.europa.eu/repository/npm-group/</code></pre></div><ul>
|
|
203
|
+
<li>Set the npm registry :</li>
|
|
204
|
+
</ul>
|
|
205
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm config set registry https://csdr-nexus.devops.tech.ec.europa.eu/repository/npm-group/</code></pre></div><ul>
|
|
206
|
+
<li>Set the always-auth flag to true to force authentication on npm registry</li>
|
|
207
|
+
</ul>
|
|
208
|
+
<p>If you are using latest version of npm (preferable > v10.3.0) always-auth is not supported and you don't have to use it. You might experience login issues while using npm version >6 and <10.</p>
|
|
209
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm config set always-auth true</code></pre></div><p>in case the config set command is not available on your version of npm, locate your .npmrc file (user directory ) and copy this to it :</p>
|
|
210
|
+
<p>always-auth=true</p>
|
|
211
|
+
<p>If you are under EC network, set the npm proxy :</p>
|
|
212
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm config set proxy http://<username>:<password>@<proxy-url>:<port>
|
|
213
|
+
npm config set https-proxy http://<username>:<password>@<proxy-url>:<port></code></pre></div><p>N.B. If the password has special characters must be encoded.</p>
|
|
214
|
+
<p>Expired Token</p>
|
|
215
|
+
<p>In case of the following error</p>
|
|
216
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm ERR! code E401
|
|
217
|
+
npm ERR! Unable to authenticate, need: BASIC realm="Sonatype Nexus Repository Manager"</code></pre></div><p>Remove the expired token from the .npmrc file and perform a new login npm adduser</p>
|
|
218
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm i -g yarn</code></pre></div><ul>
|
|
219
|
+
<li>Knowledge of eUI (refer to <a href="https://eui.ecdevops.eu">https://eui.ecdevops.eu</a> for more details)</li>
|
|
220
|
+
</ul>
|
|
221
|
+
<h3>Installation</h3>
|
|
222
|
+
<p>To start clone the <strong>csdr-root</strong> repository, to install the <strong>CSDR engine</strong> locally :</p>
|
|
223
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">git clone https://sdlc.webcloud.ec.europa.eu/csdr/csdr-root.git local-csdr (or any folder of your choice)</code></pre></div><p>After cloning this repository, in the folder of your choice, install the <b>CSDR engine</b> locally :</p>
|
|
224
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">yarn</code></pre></div><h3>How Local Setup Works</h3>
|
|
225
|
+
<p>Basically this operation will clone / setup your project and your linked UI libraries to have them ready out-of-the-box for you to directly start working on your project/application.</p>
|
|
226
|
+
<p>For each portal the installation has common parts that should be executed locally in order for your hosts to be able to be built / served on your machine.
|
|
227
|
+
For BAEP Portal, you can install all the packages of this portal cause they are limited and usually developed by the same team (see first point here under).</p>
|
|
228
|
+
<p>For MyWorkplace, a specific installation is explained, where you're installing only the repositories / packages your team is working on.
|
|
229
|
+
(as MyWorkplace contains 100+ sub packages, pulling them all on your local machine, although possible will be counter-productive in this multi-repos environment : every team / developers pull what he/she works on, rest is pulled from published dependencies of other teams)</p>
|
|
230
|
+
<h3>Setting Up a BAEP Portal Locally</h3>
|
|
231
|
+
<p>Initialize your local playground environment :</p>
|
|
232
|
+
<ul>
|
|
233
|
+
<li>Initialize the host playground, ex :</li>
|
|
234
|
+
</ul>
|
|
235
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --host baep-sandbox-host-playground --euiVersion 21.x</code></pre></div><p>where <strong>sandbox</strong> here is the name of the portal you working with given as a example portal to play with</p>
|
|
236
|
+
<p>A portal host have at least 2 mandatory repositories : refered here as <strong>UI package</strong>, initialize those 2 on your local playground folder :</p>
|
|
237
|
+
<ul>
|
|
238
|
+
<li>the <strong>home</strong> UI package, holding the home page route of your application :</li>
|
|
239
|
+
</ul>
|
|
240
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --pkg baep-sandbox-home-ui --skipInstall</code></pre></div><ul>
|
|
241
|
+
<li>the <strong>shell</strong> UI package, holding the application shell :</li>
|
|
242
|
+
</ul>
|
|
243
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --pkg baep-sandbox-shell-ui --skipInstall</code></pre></div><p><em>NB : note that the <strong>--skipInstall</strong> parameter is used here as the depedencies installation already occured in the first step of the setup : the initialization of the host</em></p>
|
|
244
|
+
<p><em>NB2 : repeat the <strong>pkg</strong> init operation as many times as you have requested specific UI packages for your own portal</em></p>
|
|
245
|
+
<ul>
|
|
246
|
+
<li>Synching your local / installing dependencies / generate CSDR config files :</li>
|
|
247
|
+
</ul>
|
|
248
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run sync</code></pre></div><h3>Running the Portal Locally</h3>
|
|
249
|
+
<p>A mock server is provided for each portal (json-server) simulating APIs calls from your frontend app, here is the command to run it locally :</p>
|
|
250
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run baep-sandbox-pl:start-mock</code></pre></div><p><em>NB: replace <strong>sandbox</strong> by your portal name</em></p>
|
|
251
|
+
<p>The app is running and is served on <a href="http://localhost:4200">http://localhost:4200</a> as a default eUI application</p>
|
|
252
|
+
<h3>Setting Up MyWorkplace Locally</h3>
|
|
253
|
+
<p>Initialize your local playground environment :</p>
|
|
254
|
+
<ul>
|
|
255
|
+
<li>Initialize the host playground, ex :</li>
|
|
256
|
+
</ul>
|
|
257
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --host my-workplace-host-playground --euiVersion EUI_VERSION --skipInstall</code></pre></div><p>Where <strong>EUI_VERSION</strong> is the eUI version of your packages you need to work on.</p>
|
|
258
|
+
<p>IMPORTANT here : you're setting up MyWorkplace according to the version of the UI package you're working on, so if your UI package(s) you want to initialize are in 19.x version of eUI, the playground host must be initialized with the same version of the package(s), a SINGLE version can only exist in your local installation, if you're working on 19.x (for your package already published in higher environments) and another 21.x because you're starting in parallel the migration of those package to say : 21.x, ANOTHER csdr-root folder for this 21.x needs to be setup, so you'll have both 19.x and 21.x installed locally in their own csdr-root local folder.</p>
|
|
259
|
+
<ul>
|
|
260
|
+
<li>Initialize your UI package as local sources :</li>
|
|
261
|
+
</ul>
|
|
262
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --pkg PKG_NAME --skipInstall</code></pre></div><ul>
|
|
263
|
+
<li>Sync locally the project to gather outside dependencies of packages produces by other teams within MyWorkplace :</li>
|
|
264
|
+
</ul>
|
|
265
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run sync</code></pre></div><p><em>NB : note that the <strong>--skipInstall</strong> parameter is used here as the depedencies installation already occured in the first step of the setup : the initialization of the host</em></p>
|
|
266
|
+
<p><em>NB2 : repeat the <strong>pkg</strong> init operation as many times as you have requested specific UI packages</em></p>
|
|
267
|
+
<h3>Running MyWorkplace with Mock Server</h3>
|
|
268
|
+
<p>A mock server is provided for each portal (json-server) simulating APIs calls from your frontend app, here is the command to run it locally :</p>
|
|
269
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run mywp-pl:start-mock</code></pre></div><h3>Running MyWorkplace with Remote API Proxy</h3>
|
|
270
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run mywp-pl:start-cdn-dev-local</code></pre></div><b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run mywp-pl:start-cdn-tst-local</code></pre></div><hr>
|
|
271
|
+
<hr>
|
|
272
|
+
<h2>Project Structure</h2>
|
|
273
|
+
<h3>Portal Host Directory Layout</h3>
|
|
274
|
+
<p>This is an example of a default BAEP host, but it's applicable to all hosts/portals,</p>
|
|
275
|
+
<table class="table table-bordered compodoc-table">
|
|
276
|
+
<thead>
|
|
277
|
+
<tr>
|
|
278
|
+
<th>Folders</th>
|
|
279
|
+
<th align="center">Description</th>
|
|
280
|
+
</tr>
|
|
281
|
+
</thead>
|
|
282
|
+
<tbody>
|
|
283
|
+
<tr>
|
|
284
|
+
<td>./config (<strong>GIT</strong>)</td>
|
|
285
|
+
<td align="center"></td>
|
|
286
|
+
</tr>
|
|
287
|
+
<tr>
|
|
288
|
+
<td>--- /remotes</td>
|
|
289
|
+
<td align="center"></td>
|
|
290
|
+
</tr>
|
|
291
|
+
<tr>
|
|
292
|
+
<td>------ /REMOTE_FOLDER</td>
|
|
293
|
+
<td align="center"></td>
|
|
294
|
+
</tr>
|
|
295
|
+
<tr>
|
|
296
|
+
<td>--------- dependencies.json</td>
|
|
297
|
+
<td align="center"></td>
|
|
298
|
+
</tr>
|
|
299
|
+
<tr>
|
|
300
|
+
<td>------ .euirc-remotes.json</td>
|
|
301
|
+
<td align="center"></td>
|
|
302
|
+
</tr>
|
|
303
|
+
<tr>
|
|
304
|
+
<td>--- .euirc-hosts.json</td>
|
|
305
|
+
<td align="center"></td>
|
|
306
|
+
</tr>
|
|
307
|
+
<tr>
|
|
308
|
+
<td>--- .euirc-packages.json</td>
|
|
309
|
+
<td align="center"></td>
|
|
310
|
+
</tr>
|
|
311
|
+
<tr>
|
|
312
|
+
<td>./metadata (<strong>GIT</strong>)</td>
|
|
313
|
+
<td align="center"></td>
|
|
314
|
+
</tr>
|
|
315
|
+
<tr>
|
|
316
|
+
<td>./hosts</td>
|
|
317
|
+
<td align="center"></td>
|
|
318
|
+
</tr>
|
|
319
|
+
<tr>
|
|
320
|
+
<td>--- /baep-sandbox-host-playground (<strong>virtual</strong>)</td>
|
|
321
|
+
<td align="center"></td>
|
|
322
|
+
</tr>
|
|
323
|
+
<tr>
|
|
324
|
+
<td>./packages</td>
|
|
325
|
+
<td align="center"></td>
|
|
326
|
+
</tr>
|
|
327
|
+
<tr>
|
|
328
|
+
<td>--- /baep-sandbox-home-ui (<strong>GIT</strong>)</td>
|
|
329
|
+
<td align="center"></td>
|
|
330
|
+
</tr>
|
|
331
|
+
<tr>
|
|
332
|
+
<td>--- /baep-sandbox-host (<strong>GIT</strong>)</td>
|
|
333
|
+
<td align="center"></td>
|
|
334
|
+
</tr>
|
|
335
|
+
<tr>
|
|
336
|
+
<td>--- /baep-sandbox-shell-ui (<strong>GIT</strong>)</td>
|
|
337
|
+
<td align="center"></td>
|
|
338
|
+
</tr>
|
|
339
|
+
<tr>
|
|
340
|
+
<td>./remotes (optional)</td>
|
|
341
|
+
<td align="center"></td>
|
|
342
|
+
</tr>
|
|
343
|
+
<tr>
|
|
344
|
+
<td>--- /baep-sandbox-home-remote-eui19 (<strong>virtual</strong>)</td>
|
|
345
|
+
<td align="center"></td>
|
|
346
|
+
</tr>
|
|
347
|
+
</tbody>
|
|
348
|
+
</table>
|
|
349
|
+
<p>In your local CSDR folder notice that you have 6 git repositories :</p>
|
|
350
|
+
<ul>
|
|
351
|
+
<li>CSDR root repository of your initial clone, this contains the necessary build tools (from eUI tools) needed for all local operations (serve/test/build, etc...) :
|
|
352
|
+
REPOSITORY (used by CSDR itself, PR impossible => call support if root configuration needs to be updated)</li>
|
|
353
|
+
<li>.config : the csdr-config where all packages/remotes/hosts definitions are set (see next point): REPOSITORY (PR possible)</li>
|
|
354
|
+
<li>hosts/PORTAL-host-playground : the playground host app of MyWorkplace to be used locally : VIRTUAL (no repository)</li>
|
|
355
|
+
<li>packages/PKG_NAME : your packages that have been initialized / corresponding each of those to a repository in gitlab : REPOSITORY</li>
|
|
356
|
+
<li>remotes/REMOTE_NAME (optional): your locally initialized remotes to do local debugging : VIRTUAL (no repository)</li>
|
|
357
|
+
</ul>
|
|
358
|
+
<p>For MyWorkplace the structure is slightly different as the host package is <strong>mywp-host-ui</strong> and there are specific repositories for <strong>config</strong> and <strong>mock</strong>, in a default portal those are located into the <strong>portal-host</strong> repository itself for simplicity reasons.</p>
|
|
359
|
+
<table class="table table-bordered compodoc-table">
|
|
360
|
+
<thead>
|
|
361
|
+
<tr>
|
|
362
|
+
<th>Folders</th>
|
|
363
|
+
<th align="center">Description</th>
|
|
364
|
+
</tr>
|
|
365
|
+
</thead>
|
|
366
|
+
<tbody>
|
|
367
|
+
<tr>
|
|
368
|
+
<td>./config (<strong>GIT</strong>)</td>
|
|
369
|
+
<td align="center"></td>
|
|
370
|
+
</tr>
|
|
371
|
+
<tr>
|
|
372
|
+
<td>--- /remotes</td>
|
|
373
|
+
<td align="center"></td>
|
|
374
|
+
</tr>
|
|
375
|
+
<tr>
|
|
376
|
+
<td>------ /REMOTE_FOLDER</td>
|
|
377
|
+
<td align="center"></td>
|
|
378
|
+
</tr>
|
|
379
|
+
<tr>
|
|
380
|
+
<td>--------- dependencies.json</td>
|
|
381
|
+
<td align="center"></td>
|
|
382
|
+
</tr>
|
|
383
|
+
<tr>
|
|
384
|
+
<td>------ .euirc-remotes.json</td>
|
|
385
|
+
<td align="center"></td>
|
|
386
|
+
</tr>
|
|
387
|
+
<tr>
|
|
388
|
+
<td>--- .euirc-hosts.json</td>
|
|
389
|
+
<td align="center"></td>
|
|
390
|
+
</tr>
|
|
391
|
+
<tr>
|
|
392
|
+
<td>--- .euirc-packages.json</td>
|
|
393
|
+
<td align="center"></td>
|
|
394
|
+
</tr>
|
|
395
|
+
<tr>
|
|
396
|
+
<td>./metadata (<strong>GIT</strong>)</td>
|
|
397
|
+
<td align="center"></td>
|
|
398
|
+
</tr>
|
|
399
|
+
<tr>
|
|
400
|
+
<td>./hosts</td>
|
|
401
|
+
<td align="center"></td>
|
|
402
|
+
</tr>
|
|
403
|
+
<tr>
|
|
404
|
+
<td>--- /my-workplace-host-playground (<strong>virtual</strong>)</td>
|
|
405
|
+
<td align="center"></td>
|
|
406
|
+
</tr>
|
|
407
|
+
<tr>
|
|
408
|
+
<td>./packages</td>
|
|
409
|
+
<td align="center"></td>
|
|
410
|
+
</tr>
|
|
411
|
+
<tr>
|
|
412
|
+
<td>--- /mywp-host-ui (<strong>GIT</strong>)</td>
|
|
413
|
+
<td align="center"></td>
|
|
414
|
+
</tr>
|
|
415
|
+
<tr>
|
|
416
|
+
<td>--- /mywp-config (<strong>GIT</strong>)</td>
|
|
417
|
+
<td align="center"></td>
|
|
418
|
+
</tr>
|
|
419
|
+
<tr>
|
|
420
|
+
<td>--- /mywp-mock (<strong>GIT</strong>)</td>
|
|
421
|
+
<td align="center"></td>
|
|
422
|
+
</tr>
|
|
423
|
+
<tr>
|
|
424
|
+
<td>--- /YOUR_UI_PACKAGE(s) (<strong>GIT</strong>)</td>
|
|
425
|
+
<td align="center"></td>
|
|
426
|
+
</tr>
|
|
427
|
+
<tr>
|
|
428
|
+
<td>./remotes (optional)</td>
|
|
429
|
+
<td align="center"></td>
|
|
430
|
+
</tr>
|
|
431
|
+
<tr>
|
|
432
|
+
<td>--- /mywp-dashboard-remote-eui21 (<strong>virtual</strong>)</td>
|
|
433
|
+
<td align="center"></td>
|
|
434
|
+
</tr>
|
|
435
|
+
</tbody>
|
|
436
|
+
</table>
|
|
437
|
+
<p>packages/mywp-config : the API gateway / openid configuration files per environment (more on this later) : REPOSITORY (PR possible)
|
|
438
|
+
packages/mywp-host-ui : the actual source code of the MWP app, injected at build/serve time : REPOSITORY (PR possible)
|
|
439
|
+
packages/mywp-mock : used for local development for UI standalone development without any backend connection (more on this later) : REPOSITORY (PR possible)</p>
|
|
440
|
+
<h3>UI Package Structure</h3>
|
|
441
|
+
<p>Once a UI package is requested to be created, a raw package skeleton pre-configured will be available for you to start developing your own business section
|
|
442
|
+
in a portal / in MyWorkplace.</p>
|
|
443
|
+
<h4>Structure of a UI package skeleton</h4>
|
|
444
|
+
<table class="table table-bordered compodoc-table">
|
|
445
|
+
<thead>
|
|
446
|
+
<tr>
|
|
447
|
+
<th>Folders</th>
|
|
448
|
+
<th align="center">Description</th>
|
|
449
|
+
</tr>
|
|
450
|
+
</thead>
|
|
451
|
+
<tbody>
|
|
452
|
+
<tr>
|
|
453
|
+
<td>./packages/sample-package-ui (<strong>GIT</strong>)</td>
|
|
454
|
+
<td align="center"></td>
|
|
455
|
+
</tr>
|
|
456
|
+
<tr>
|
|
457
|
+
<td>--- /assets</td>
|
|
458
|
+
<td align="center"></td>
|
|
459
|
+
</tr>
|
|
460
|
+
<tr>
|
|
461
|
+
<td>------ /i18n</td>
|
|
462
|
+
<td align="center"></td>
|
|
463
|
+
</tr>
|
|
464
|
+
<tr>
|
|
465
|
+
<td>--- /src</td>
|
|
466
|
+
<td align="center"></td>
|
|
467
|
+
</tr>
|
|
468
|
+
<tr>
|
|
469
|
+
<td>------ /lib</td>
|
|
470
|
+
<td align="center"></td>
|
|
471
|
+
</tr>
|
|
472
|
+
<tr>
|
|
473
|
+
<td>--------- /components</td>
|
|
474
|
+
<td align="center"></td>
|
|
475
|
+
</tr>
|
|
476
|
+
<tr>
|
|
477
|
+
<td>------------ main.component.html</td>
|
|
478
|
+
<td align="center"></td>
|
|
479
|
+
</tr>
|
|
480
|
+
<tr>
|
|
481
|
+
<td>------------ main.component.ts</td>
|
|
482
|
+
<td align="center"></td>
|
|
483
|
+
</tr>
|
|
484
|
+
<tr>
|
|
485
|
+
<td>--------- module.ts</td>
|
|
486
|
+
<td align="center"></td>
|
|
487
|
+
</tr>
|
|
488
|
+
<tr>
|
|
489
|
+
<td>------ dummy.spec.ts</td>
|
|
490
|
+
<td align="center"></td>
|
|
491
|
+
</tr>
|
|
492
|
+
<tr>
|
|
493
|
+
<td>------ index.ts</td>
|
|
494
|
+
<td align="center"></td>
|
|
495
|
+
</tr>
|
|
496
|
+
<tr>
|
|
497
|
+
<td>--- .eslintrc.json</td>
|
|
498
|
+
<td align="center"></td>
|
|
499
|
+
</tr>
|
|
500
|
+
<tr>
|
|
501
|
+
<td>--- .gitignore</td>
|
|
502
|
+
<td align="center"></td>
|
|
503
|
+
</tr>
|
|
504
|
+
<tr>
|
|
505
|
+
<td>--- .gitlab-ci.yml</td>
|
|
506
|
+
<td align="center"></td>
|
|
507
|
+
</tr>
|
|
508
|
+
<tr>
|
|
509
|
+
<td>--- dependencies-base.json</td>
|
|
510
|
+
<td align="center"></td>
|
|
511
|
+
</tr>
|
|
512
|
+
<tr>
|
|
513
|
+
<td>--- dependencies-composite.json</td>
|
|
514
|
+
<td align="center"></td>
|
|
515
|
+
</tr>
|
|
516
|
+
<tr>
|
|
517
|
+
<td>--- ....</td>
|
|
518
|
+
<td align="center"></td>
|
|
519
|
+
</tr>
|
|
520
|
+
<tr>
|
|
521
|
+
<td>--- package.json</td>
|
|
522
|
+
<td align="center"></td>
|
|
523
|
+
</tr>
|
|
524
|
+
<tr>
|
|
525
|
+
<td>--- tsconfig.lib.json</td>
|
|
526
|
+
<td align="center"></td>
|
|
527
|
+
</tr>
|
|
528
|
+
<tr>
|
|
529
|
+
<td>--- tsconfig.spec.json</td>
|
|
530
|
+
<td align="center"></td>
|
|
531
|
+
</tr>
|
|
532
|
+
</tbody>
|
|
533
|
+
</table>
|
|
534
|
+
<h4>Key files in details</h4>
|
|
535
|
+
<p><strong>assets/i18n - package key/value translations</strong>
|
|
536
|
+
fr.json and en.json allowing you to set translation keys for your labels within your templates (using ngx-translate pipe)</p>
|
|
537
|
+
<p>in the form of :</p>
|
|
538
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
539
|
+
"sample-package-name.KEY": "value"
|
|
540
|
+
}
|
|
541
|
+
</code></pre></div><p><strong>.gitlab-ci.yml - default CSDR component for package pipeline build</strong></p>
|
|
542
|
+
<p>package pipeline is one stage : build to handle the package release : linting / auditing / testing / building / sonar scanning / publishing</p>
|
|
543
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">stages: [build]
|
|
544
|
+
|
|
545
|
+
include:
|
|
546
|
+
- component: $CI_SERVER_FQDN/csdr/csdr-templates/shared-components/package-release@master</code></pre></div><p><strong>dependencies-base.json and dependencies-composite.json - what the package depends on externally and internally</strong></p>
|
|
547
|
+
<p>Those 2 key files are used for setting dependencies of the package, they are recognized by the CSDR engine when installing locally / on CI.</p>
|
|
548
|
+
<p><strong>dependencies-base.json</strong> is where you'll put your 3rd party dependencies / 3rd party meaning not built by CSDR, in that file you're setting the actual version of the libs the package is depending on :</p>
|
|
549
|
+
<p>For example, you're using ngRx in your package and you need to use moment for date formatting (default package base deps in MyWorkplace)</p>
|
|
550
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
551
|
+
"@ngrx/component-store": "^21.0.0",
|
|
552
|
+
"@ngrx/effects": "^21.0.0",
|
|
553
|
+
"@ngrx/entity": "^21.0.0",
|
|
554
|
+
"@ngrx/operators": "^21.0.0",
|
|
555
|
+
"@ngrx/router-store": "^21.0.0",
|
|
556
|
+
"@ngrx/signals": "^21.0.0",
|
|
557
|
+
"@ngrx/store": "^21.0.0",
|
|
558
|
+
"moment": "2.30.1",
|
|
559
|
+
"moment-timezone": "0.6.0"
|
|
560
|
+
}</code></pre></div><p><strong>dependencies-composite.json</strong></p>
|
|
561
|
+
<p>At the contrary of dependencies-base.json seen earlier, the <strong>composite</strong> file is where you'll declare dependencies / UI packages that are built by CSDR itself.
|
|
562
|
+
Why <strong>composite</strong>? Because when installing, the composition of those dependencies will be made according to where you're installing to : locally / DEV environment OR upper environment specific.</p>
|
|
563
|
+
<p><em>all the dependencies defined here should be ALWAYS caret base : ^x.0.0</em>, as CSDR will only take care of the major version of the package installed, and will <strong>compose</strong> the real version
|
|
564
|
+
(either be latest snapshot or latest release of the package) according to where it's installed to.</p>
|
|
565
|
+
<p>Example of a typical package in MyWorkplace, where eUI is set (as part of the CSDR repositories too) and other shared libraries the package is depending on :</p>
|
|
566
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
567
|
+
"@eui/deps-base": "^21.0.0",
|
|
568
|
+
"@csdr/core": "^9.0.0",
|
|
569
|
+
"@mywp/shared": "^9.0.0"
|
|
570
|
+
}</code></pre></div><p>Once installing locally, those dependencies will be composed with all the dependencies of locally initialized packages you have and the host, resulting in a full global install of all dependencies
|
|
571
|
+
all the packages need locally. Here in this case the latest versions (including snapshots so built from the respective develop branch of the package) of ALL dependencies set with major caret will be installed (if existing).</p>
|
|
572
|
+
<p><strong>package.json</strong></p>
|
|
573
|
+
<p>Shouldn't be touched, except to raise the version during a migration phase (see migration chapter), the version / tag are auto-generated by the CSDR pipeline itself.</p>
|
|
574
|
+
<hr>
|
|
575
|
+
<hr>
|
|
576
|
+
<h2>CSDR configuration repository</h2>
|
|
577
|
+
<p>It holds the configuration for all assets for every host portals created, mainly : the hosts / the packages / the remotes, under the BAEP scope.
|
|
578
|
+
The configuration for all elements is set when they are created, after that if needed you can send PR to adjust it if really necessary,
|
|
579
|
+
keep in mind that the "skip" options are there for a reason, skipping test/linting or audit might be the result that the code of the package need some refactoring to avoid long term technical debts, poor or zero unit testing, or unnecessary css customization that should be tackled.</p>
|
|
580
|
+
<h3>Packages configuration</h3>
|
|
581
|
+
<p>Each entry represents the name of the UI package and the npm package name as it will be published on the registry once released.</p>
|
|
582
|
+
<p>As per convention, there's no mention of the <strong>git</strong> repository name as it's always the name of the package itself in gitlab,
|
|
583
|
+
only the <strong>subgroup</strong> is defined here and correspond to the portal name where the <strong>UI package</strong> belongs to.
|
|
584
|
+
It's optional, as <strong>shared library</strong> package could belong to the root of the CSDR gitlab projects group.</p>
|
|
585
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"packageName-ui": {
|
|
586
|
+
"npmPkg": "@scope/packageName",
|
|
587
|
+
"subgroup": "host-subgroup",
|
|
588
|
+
"notificationChannel": "pipeline-ui" (default)
|
|
589
|
+
}</code></pre></div><p>Same as some options could be provided when you'll execute the <strong>build</strong> command on the command-line
|
|
590
|
+
(npm run pkg:build packageName), same options can be provided in the <strong>build</strong> property of the package configuration :</p>
|
|
591
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"baep-packageName-ui": {
|
|
592
|
+
"npmPkg": "@scope/packageName",
|
|
593
|
+
"subgroup": "host-subgroup",
|
|
594
|
+
"build": {
|
|
595
|
+
"skipLint": true,
|
|
596
|
+
"skipTest": true,
|
|
597
|
+
"eslintRelaxed": true
|
|
598
|
+
}
|
|
599
|
+
}</code></pre></div><p>Note that the <strong>eslintRelaxed</strong> option instructs the package to use an esLint config less aggressive, used for migrating a package from an earlier version,
|
|
600
|
+
to let the team the time to progressively fix (if they want to) their linting errors, this is recommended as linting errors most of the times indicate bad coding practices / modernization to be applied on the code of the package itself, reducing tech debts, etc...</p>
|
|
601
|
+
<h3>Virtual deployed host configuration</h3>
|
|
602
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"baep-sandbox": {
|
|
603
|
+
"shortName": "SANDBOX",
|
|
604
|
+
"hostName": "baep-sandbox",
|
|
605
|
+
"folder": "hosts/baep-sandbox",
|
|
606
|
+
"playground": false,
|
|
607
|
+
"scopes": "eui,csdr,baep",
|
|
608
|
+
"hostPackage": "@baep/sandbox-host",
|
|
609
|
+
"distribution": {
|
|
610
|
+
"envs": {
|
|
611
|
+
"dev": {
|
|
612
|
+
"baseHref": "TO_DO",
|
|
613
|
+
"bucket": "TO_DO"
|
|
614
|
+
},
|
|
615
|
+
"tst": {
|
|
616
|
+
"baseHref": "TO_DO",
|
|
617
|
+
"bucket": "TO_DO"
|
|
618
|
+
},
|
|
619
|
+
"acc": {
|
|
620
|
+
"baseHref": "TO_DO",
|
|
621
|
+
"bucket": "TO_DO"
|
|
622
|
+
},
|
|
623
|
+
"prd": {
|
|
624
|
+
"baseHref": "TO_DO",
|
|
625
|
+
"bucket": "TO_DO"
|
|
626
|
+
},
|
|
627
|
+
}
|
|
628
|
+
},
|
|
629
|
+
"envSequence": [
|
|
630
|
+
"dev",
|
|
631
|
+
"tst",
|
|
632
|
+
"acc",
|
|
633
|
+
"prd"
|
|
634
|
+
],
|
|
635
|
+
"pivotEnv": "tst"
|
|
636
|
+
}
|
|
637
|
+
</code></pre></div><p>This host config will be the one used for the deployed host on the server, you'll barely use it / see it locally, although it can be initialized as the playground host to simulate a build of it locally.</p>
|
|
638
|
+
<p>Let's review some config options :</p>
|
|
639
|
+
<p><strong>folder</strong>
|
|
640
|
+
Local folder where the host will be generated</p>
|
|
641
|
+
<p><strong>scopes</strong>
|
|
642
|
+
The package dependencies scopes that will be used to compile translations from all scoped packages that will be used for the host translations,
|
|
643
|
+
at build time the scope of the package set will be scanned and all of their assets/i18n will be compiled, concatenated by language, making them available for the host once translations will be loaded at runtime.</p>
|
|
644
|
+
<p><strong>hostPackage</strong>
|
|
645
|
+
The host package linked to the host used for generate it based on config and app-sources</p>
|
|
646
|
+
<p><strong>distribution</strong>
|
|
647
|
+
For each environment, instruct where to send the built / distribution files to the S3 locations provided, setting the baseHref for each env</p>
|
|
648
|
+
<p><strong>envSequence</strong>
|
|
649
|
+
The sequence of the environments where the host will be deployed to, this also cover the remote associated with the host itself, they'll follow the same sequence.</p>
|
|
650
|
+
<p><strong>pivotEnv</strong>
|
|
651
|
+
The env used as pivot from where next generated major of the host will be incremented</p>
|
|
652
|
+
<h3>Virtual local playground host configuration</h3>
|
|
653
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"baep-sandbox-host-playground": {
|
|
654
|
+
"hostName": "baep-sandbox",
|
|
655
|
+
"folder": "hosts/baep-sandbox-host-playground",
|
|
656
|
+
"playground": true,
|
|
657
|
+
"scopes": "eui,csdr,baep",
|
|
658
|
+
"hostPackage": "@baep/sandbox-host"
|
|
659
|
+
}</code></pre></div><p>This is basically used by the host playground for local developmnent, same as for the host, scopes can be adjusted so to playground knows about which package scopes to get the translation assets (assets/i18n folder of your package) to be compiled from.</p>
|
|
660
|
+
<p>It is "linked" to the deployed "host" (see host configuration in previous point) sharing the same : <strong>hostName</strong> config entry.</p>
|
|
661
|
+
<h3>Virtual remote definition</h3>
|
|
662
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"baep-sandbox-home-remote-eui21": {
|
|
663
|
+
"npmPkg": "@baep/sandbox-home-remote-eui21",
|
|
664
|
+
"linkedHost": "baep-sandbox",
|
|
665
|
+
"euiVersion": "21.x",
|
|
666
|
+
"build": {
|
|
667
|
+
"compiledTranslations": true,
|
|
668
|
+
"translationScopes": "eui,csdr,baep",
|
|
669
|
+
"envTargetActive": true,
|
|
670
|
+
"sonarScanner": false
|
|
671
|
+
},
|
|
672
|
+
"skeletonConfig": {
|
|
673
|
+
"rootNpmPkg": "@baep/sandbox-home",
|
|
674
|
+
"rootCommonModule": "HomeModule",
|
|
675
|
+
"baseUrl": "home",
|
|
676
|
+
"elementName": "baep-sandbox-home-v21",
|
|
677
|
+
"storeName": "baep-sandbox-home-v21"
|
|
678
|
+
},
|
|
679
|
+
"msteams": {
|
|
680
|
+
"channel": "pipeline-ui"
|
|
681
|
+
}
|
|
682
|
+
}</code></pre></div><p>Some important configuration metadata :</p>
|
|
683
|
+
<p><strong>rootNpmPkg</strong>
|
|
684
|
+
The name of your section package, the linked UI package to the remote</p>
|
|
685
|
+
<p><strong>rootCommonModule</strong>
|
|
686
|
+
The name of the main module exported in your section UI package</p>
|
|
687
|
+
<p><strong>baseUrl</strong>
|
|
688
|
+
The path your section will be reachable to</p>
|
|
689
|
+
<p><strong>elementName</strong>
|
|
690
|
+
The tag for the custom element: it must be unique</p>
|
|
691
|
+
<h4>Remote dependencies configuration</h4>
|
|
692
|
+
<p>Each of the known remote to CSDR is having a specific folder corresponding to the remote name for storing their dependencies configuration, located in <strong>csdr-config/remotes</strong> folder.</p>
|
|
693
|
+
<p>This <strong>dependencies.json</strong> file allows to controls what the remote will depend on when it'll be independently built.</p>
|
|
694
|
+
<p>There are 3 mains parts :</p>
|
|
695
|
+
<ul>
|
|
696
|
+
<li>the <strong>base</strong>, it's the location to put all 3rd party dependencies libraries that the remote might depend on.</li>
|
|
697
|
+
<li>the <strong>composite</strong>, it's the location to put all dependencies known in the CSDR ecosystem, once the installation of the remote will happen, those <strong>carret</strong> dependencies will be resolved as either the <strong>lastet snapshots</strong> releases for <strong>DEV</strong> target builds and deployments OR the <strong>latest</strong> dependencies for <strong>TST</strong> and up deployment.</li>
|
|
698
|
+
<li>the <strong>locked by environment</strong> groups, is optional and it's used to force dependencies known in the <strong>composite</strong> to specific version to specific environments. In the case for example, you don't want right away to push a dependency part of the group but there's a bugfix for another in the group.</li>
|
|
699
|
+
</ul>
|
|
700
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
701
|
+
"base": {
|
|
702
|
+
},
|
|
703
|
+
"composite": {
|
|
704
|
+
"@eui/deps-base": "^18.0.0",
|
|
705
|
+
"@csdr/core": "^7.0.0",
|
|
706
|
+
"@csdr/integration": "^6.0.0",
|
|
707
|
+
"@baep/sandbox-home": "^1.0.0"
|
|
708
|
+
},
|
|
709
|
+
"int": {
|
|
710
|
+
},
|
|
711
|
+
"acc": {
|
|
712
|
+
},
|
|
713
|
+
"prd": {
|
|
714
|
+
}
|
|
715
|
+
}</code></pre></div><hr>
|
|
716
|
+
<hr>
|
|
717
|
+
<h2>Portal Host repository</h2>
|
|
718
|
+
<h3>Host Source Injection and Virtual Host Generation</h3>
|
|
719
|
+
<p>Each portal have configuration set in a specific repository : <strong>PORTAL_NAME-host</strong>.
|
|
720
|
+
The sources will be injected to generate the virtual host / reconstruct the host either to be deployed on environment the <strong>host</strong> or locally with the <strong>host-playground</strong>.</p>
|
|
721
|
+
<p>It contains specific sources / host config files per eUI version, that allows locally / once deployed on server to work on different eUI version of the host in parallel.</p>
|
|
722
|
+
<p>Here is the structure of the <strong>PORTAL_NAME-host</strong> repository :</p>
|
|
723
|
+
<table class="table table-bordered compodoc-table">
|
|
724
|
+
<thead>
|
|
725
|
+
<tr>
|
|
726
|
+
<th>Folders</th>
|
|
727
|
+
<th>Description</th>
|
|
728
|
+
</tr>
|
|
729
|
+
</thead>
|
|
730
|
+
<tbody>
|
|
731
|
+
<tr>
|
|
732
|
+
<td>./[eUI version : 18.x - 19.x - 21.x]</td>
|
|
733
|
+
<td></td>
|
|
734
|
+
</tr>
|
|
735
|
+
<tr>
|
|
736
|
+
<td>--- ./app-root</td>
|
|
737
|
+
<td></td>
|
|
738
|
+
</tr>
|
|
739
|
+
<tr>
|
|
740
|
+
<td>------ ...</td>
|
|
741
|
+
<td></td>
|
|
742
|
+
</tr>
|
|
743
|
+
<tr>
|
|
744
|
+
<td>------ dependencies-base.json</td>
|
|
745
|
+
<td></td>
|
|
746
|
+
</tr>
|
|
747
|
+
<tr>
|
|
748
|
+
<td>------ dependencies-composite.json</td>
|
|
749
|
+
<td></td>
|
|
750
|
+
</tr>
|
|
751
|
+
<tr>
|
|
752
|
+
<td>------ ...</td>
|
|
753
|
+
<td></td>
|
|
754
|
+
</tr>
|
|
755
|
+
<tr>
|
|
756
|
+
<td>--- ./app-root-playground</td>
|
|
757
|
+
<td></td>
|
|
758
|
+
</tr>
|
|
759
|
+
<tr>
|
|
760
|
+
<td>------ ...</td>
|
|
761
|
+
<td></td>
|
|
762
|
+
</tr>
|
|
763
|
+
<tr>
|
|
764
|
+
<td>------ dependencies-base.json</td>
|
|
765
|
+
<td></td>
|
|
766
|
+
</tr>
|
|
767
|
+
<tr>
|
|
768
|
+
<td>------ dependencies-composite.json</td>
|
|
769
|
+
<td></td>
|
|
770
|
+
</tr>
|
|
771
|
+
<tr>
|
|
772
|
+
<td>------ ...</td>
|
|
773
|
+
<td></td>
|
|
774
|
+
</tr>
|
|
775
|
+
<tr>
|
|
776
|
+
<td>--- ./app-sources</td>
|
|
777
|
+
<td></td>
|
|
778
|
+
</tr>
|
|
779
|
+
<tr>
|
|
780
|
+
<td>./config</td>
|
|
781
|
+
<td>see API configuration section</td>
|
|
782
|
+
</tr>
|
|
783
|
+
<tr>
|
|
784
|
+
<td>./mock</td>
|
|
785
|
+
<td>see API configuration section</td>
|
|
786
|
+
</tr>
|
|
787
|
+
<tr>
|
|
788
|
+
<td>./routes</td>
|
|
789
|
+
<td>see Routes configuration section</td>
|
|
790
|
+
</tr>
|
|
791
|
+
</tbody>
|
|
792
|
+
</table>
|
|
793
|
+
<p><strong>app-root folder</strong></p>
|
|
794
|
+
<p>It contains the configuration / dependencies for the real released host on server, so it basically depends on eUI and the host shell packages and no packages that will be wrapped as micro-frontend within the remotes themselves.</p>
|
|
795
|
+
<p><strong>app-root-playground folder</strong></p>
|
|
796
|
+
<p>It contains the configuration / dependencies of <strong>ALL</strong> packages within the host, and exclusively to be used locally according to the eUI version you're working against, see that as a monolith which depends on dozens of sub-packages.</p>
|
|
797
|
+
<p><strong>app-sources</strong></p>
|
|
798
|
+
<p>Those are common to both hosts types (host and host-playground) and are basically the top root sources of an eUI Angular application, app-wide defitions and configuration / assets / base routes etc...</p>
|
|
799
|
+
<p><strong>config</strong></p>
|
|
800
|
+
<p>It's the <strong>API</strong> definitions of your app, defined by environment, based on the env_target you're deploying to, the specific environment file will be injected at build time of the host for release.</p>
|
|
801
|
+
<p>(Note that this package can be an external dependency / repository / package, in MyWorkplace the config is located in the <strong>mywp-config</strong> repository and released separately)</p>
|
|
802
|
+
<p><strong>mock</strong></p>
|
|
803
|
+
<p>It's the json-server / express mock server for using your portal locally without any backend / API connection.</p>
|
|
804
|
+
<p>(Note that this package can be an external repository / package, in MyWorkplace the mock server is located in the <strong>mywp-mock</strong> repository)</p>
|
|
805
|
+
<p><strong>routes</strong>
|
|
806
|
+
(see next point)</p>
|
|
807
|
+
<h3>Routes Definitions</h3>
|
|
808
|
+
<p>Inside a portal/host, each micro-frontend is associated to a specific entry route of the host. Those are defined per distributed environment, where the micro-frontend / remotes are loaded at runtime, using the <strong>csdr element-loader</strong> service when users are navigating to the corresponding route.</p>
|
|
809
|
+
<p>Within the <strong>PORTAL_NAME-host</strong> folder/repository (or <strong>mywp-host-ui</strong> in case of MyWorkplace), a specific <strong>routes</strong> folder lets you declare your routes, both for the deployed <strong>host</strong> and for the <strong>local host playground</strong>.</p>
|
|
810
|
+
<p>At serve time and build time, those routes will definitions will generate the entire routes mapping of your host/portal, the CSDR engine will replace the <strong>PORTAL_NAME-host/assets/EUI_VERSION/app-sources/app.routes-base.ts</strong> placeholder by the complete set of routes for the environment targeted (or the local playground once served).</p>
|
|
811
|
+
<p>The route definitions are defined per environment wether be a real environment (dev, tst, acc, prd) or local one (playground).</p>
|
|
812
|
+
<p>Each of the <strong>path</strong> are mapping the url on which the <strong>remote</strong> micro-frontend will be dynamically loaded with the definitions of the remotes themselves.</p>
|
|
813
|
+
<p>Note that when a new package / section is created (so remote associated with a path/route in your portal), the route definitions will be automatically created as a starting point, so all entries presented here in the route documentation will be already pre-configured.</p>
|
|
814
|
+
<h4>The routes-defs-base.json central link between the route path and the remotes</h4>
|
|
815
|
+
<p>In the <strong>PORTAL_NAME-host/assets/EUI_VERSION/routes/routes-defs-base.json</strong> file, you will find all the remotes defined for a specific portal.</p>
|
|
816
|
+
<p>Here as an example the default <strong>home</strong> path (/home) linked to the <strong>baep-sandbox-home-remote-eui21</strong> remote :</p>
|
|
817
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">[
|
|
818
|
+
{
|
|
819
|
+
"path": "home",
|
|
820
|
+
"title": "Home",
|
|
821
|
+
"lazyLoadDef": {
|
|
822
|
+
"npmPkg": "@baep/sandbox-home",
|
|
823
|
+
"moduleName": "HomeModule"
|
|
824
|
+
},
|
|
825
|
+
"remoteDefs": [
|
|
826
|
+
{
|
|
827
|
+
"euiVersion": "19.x",
|
|
828
|
+
"moduleId": "baep-sandbox-home-remote-eui19",
|
|
829
|
+
"elementTag": "baep-sandbox-home-remote-v19"
|
|
830
|
+
}
|
|
831
|
+
]
|
|
832
|
+
}
|
|
833
|
+
]</code></pre></div><p>2 main entries are defined :</p>
|
|
834
|
+
<ul>
|
|
835
|
+
<li><p><strong>lazyLoadDefs</strong> : instructing which module to load when the host is served as an host-playground locally, it applies lazy-loading of the root module of the remote, from the UI package linked to the remote itself : here the <strong>@baep/sandbox-home</strong> referring to the <strong>baep-sandbox-home-ui</strong> from the <strong>./packages/baep-sandbox-home-ui</strong> folder/repository initialized in your local playground environment if the packages has been initialized as sources.
|
|
836
|
+
For the packages that the host-playground local installation is depending on, the module will be the ones installed in the local node_modules of each package the host playground is depending on.</p>
|
|
837
|
+
</li>
|
|
838
|
+
<li><p><strong>remoteDefs</strong> : defining the remote associated to the <strong>home</strong> path, here the <strong>baep-sandbox-home-remote-eui19</strong>, where the eUI version of the remote is also declared, as multiple remote of different eUI version can co-exists within the same host or among the different environments of your portal.</p>
|
|
839
|
+
</li>
|
|
840
|
+
</ul>
|
|
841
|
+
<p>Once a new version of the remote needs to be setup, a new entry of that <strong>remoteDefs</strong> should be created, so for example here, if the <strong>baep-sandbox-home-remote-eui19</strong> is migrated to a <strong>baep-sandbox-home-remote-eui21</strong>, a new entry for this eui21 remote version should be added :
|
|
842
|
+
(see migration section for more info)</p>
|
|
843
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">[
|
|
844
|
+
{
|
|
845
|
+
"path": "home",
|
|
846
|
+
"title": "Home",
|
|
847
|
+
"lazyLoadDef": {
|
|
848
|
+
"npmPkg": "@baep/sandbox-home",
|
|
849
|
+
"moduleName": "HomeModule"
|
|
850
|
+
},
|
|
851
|
+
"remoteDefs": [
|
|
852
|
+
{
|
|
853
|
+
"euiVersion": "19.x",
|
|
854
|
+
"moduleId": "baep-sandbox-home-remote-eui19",
|
|
855
|
+
"elementTag": "baep-sandbox-home-remote-v19"
|
|
856
|
+
},
|
|
857
|
+
{
|
|
858
|
+
"euiVersion": "21.x",
|
|
859
|
+
"moduleId": "baep-sandbox-home-remote-eui21",
|
|
860
|
+
"elementTag": "baep-sandbox-home-remote-v21"
|
|
861
|
+
}
|
|
862
|
+
]
|
|
863
|
+
}
|
|
864
|
+
]</code></pre></div><h4>The route-defs-base-links-ENV.json - UI menu links within the portal</h4>
|
|
865
|
+
<p>On the portal itself, the way those route are accessed can be of 2 types :</p>
|
|
866
|
+
<ul>
|
|
867
|
+
<li>A direct entry within the sidebar menu, here the links per environment file OR</li>
|
|
868
|
+
<li>The remote is defined with a route that is programmatically routed from one of the other routed remote defined in the portal (sub-route / details routes etc...), for example in MyWorkplace <strong>task center</strong> as a link defined, while <strong>task-details</strong> hasn't, as it's a route triggered from task-center itself, so no direct access is found in the main menu of the host, but a route definition do exist for it.</li>
|
|
869
|
+
</ul>
|
|
870
|
+
<p>Here the <strong>route-defs-base-links-ENV.json</strong> file defines the sidebar direct entry routes for the portal, there is one file per environment to let you have a fine-grain customization of which routes / linked to a remote is activated on each of the environment of the portal.</p>
|
|
871
|
+
<p>Here is an example for the complete home link of the <strong>home</strong> path defined as a direct entry route :</p>
|
|
872
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">[
|
|
873
|
+
{
|
|
874
|
+
"id": "home",
|
|
875
|
+
"url": "/home",
|
|
876
|
+
"label": "Home",
|
|
877
|
+
"iconSvgName": "home:outline",
|
|
878
|
+
"optional": true
|
|
879
|
+
}
|
|
880
|
+
]</code></pre></div><p>You can define here a label for the route, an icon (iconSvgName following the eui-menu interface and the eui-icon-svg property), and a unique id to refer to the route within the app if needed (customization of routes, ...).</p>
|
|
881
|
+
<p>The <strong>url</strong> : /home will try to match the definitions of the route <strong>path</strong> in the <strong>route-defs-base.json</strong> file as presented earlier, and either load the remote from the <strong>remoteDefs</strong> entry OR the <strong>lazyLoadDefs</strong> entry if you're running the portal in the local playground environment.</p>
|
|
882
|
+
<p>As an alternative option, to avoid defining and copying all the times the same links definitions for all environment, the menu links can be defined from within the <strong>routes-defs-base.json</strong> entries for each path.</p>
|
|
883
|
+
<p>Here is an example, for MyWorkplace dashboard, the path entry in the <strong>routes-defs-base.json</strong> is as follows : </p>
|
|
884
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none"> {
|
|
885
|
+
"path": "home",
|
|
886
|
+
"title": "Home",
|
|
887
|
+
"menuLinkDefs": [
|
|
888
|
+
{
|
|
889
|
+
"url": "/home",
|
|
890
|
+
"label": "sidebar-link.DASHBOARD",
|
|
891
|
+
"iconSvgName": "home:outline"
|
|
892
|
+
}
|
|
893
|
+
],
|
|
894
|
+
"lazyLoadDef": {
|
|
895
|
+
"npmPkg": "@mywp/dashboard",
|
|
896
|
+
"moduleName": "MywpDashboardModule"
|
|
897
|
+
},
|
|
898
|
+
"remoteDefs": [
|
|
899
|
+
{
|
|
900
|
+
"euiVersion": "21.x",
|
|
901
|
+
"moduleId": "mywp-dashboard-eui21-remote-el-ui",
|
|
902
|
+
"elementTag": "mywp-dashboard-v21"
|
|
903
|
+
}
|
|
904
|
+
]
|
|
905
|
+
}</code></pre></div><p>As you can see the <strong>menuLinkDefs</strong> is setting and defining a link entry for the <strong>/home</strong> path a label and an iconSvgName and this will be used for all links in all environments.</p>
|
|
906
|
+
<p>If we look at the <strong>route-defs-base-links-dev.json</strong> and the <strong>route-defs-base-links-tst.json</strong> (and for all other environment), the links are just declaring the path entry, without the metadata (label / iconSvgName here) : </p>
|
|
907
|
+
<p>route-defs-base-link-dev.json : </p>
|
|
908
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none"> {
|
|
909
|
+
"id": "home",
|
|
910
|
+
"url": "/home"
|
|
911
|
+
}</code></pre></div><p>route-defs-base-links-tst.json :</p>
|
|
912
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none"> {
|
|
913
|
+
"id": "home",
|
|
914
|
+
"url": "/home"
|
|
915
|
+
}</code></pre></div><h4>The route-defs-base-EUI_VERSION-playground.json or "how to define how a route will be loaded in playground local environment"</h4>
|
|
916
|
+
<p>As said earlier, the playground environment route loads by default from the <strong>lazyLoadDefs</strong> of the route-defs-base.json definitions, on each entry, the associated <strong>path</strong> is therefore marked as to be loaded <strong>lazy</strong> here is an example :</p>
|
|
917
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">
|
|
918
|
+
[
|
|
919
|
+
{
|
|
920
|
+
"path": "home",
|
|
921
|
+
"lazy": true
|
|
922
|
+
}
|
|
923
|
+
]</code></pre></div><p>when the <strong>home</strong> route path will be navigated to, the <strong>lazy</strong> definitions will be loaded, which is corresponding to the entry in the <strong>route-defs-base.json</strong> / <strong>lazyLoadDefs</strong> : here the HomeModule, from the <strong>home</strong> UI package sources within your local environment.</p>
|
|
924
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"path": "home",
|
|
925
|
+
"title": "Home",
|
|
926
|
+
"lazyLoadDef": {
|
|
927
|
+
"npmPkg": "@baep/sandbox-home",
|
|
928
|
+
"moduleName": "HomeModule"
|
|
929
|
+
},
|
|
930
|
+
...</code></pre></div><h4>The route-defs-ENV.json or "how to define how a route will be loaded on the deployed host on a specific environment"</h4>
|
|
931
|
+
<p>Once the host is deployed, it relies only on the <strong>remotes</strong> / micro-frontend to be loaded dynamically as they're released independently of the main host too.</p>
|
|
932
|
+
<p>In order to instruct which remote in which version to load on a specific environment, the <strong>route-defs-ENV.json</strong> file is used / one per each environment that you're targeting for the host / remote deployment :</p>
|
|
933
|
+
<p>Here the <strong>path</strong> is instructed to load the remote as defined in the <strong>remoteDefs</strong> of the <strong>route-defs-base.json</strong>, and the specific eUI version of it.</p>
|
|
934
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">[
|
|
935
|
+
{
|
|
936
|
+
"path": "home",
|
|
937
|
+
"remote": true,
|
|
938
|
+
"euiVersion": "19.x"
|
|
939
|
+
}
|
|
940
|
+
]</code></pre></div><p>Note that : by default all paths are associated to remotes being loaded once deployed, in some case, you can load lazy routes from dependencies from the host itself as normal sub-package being loaded, the <strong>lazy</strong> option is also working on this environment definitions file (if needed and ONLY IF the host is depending directly on the package dependency itself).</p>
|
|
941
|
+
<h3>Workspaces definitions (available for MyWorkplace)</h3>
|
|
942
|
+
<p>In MyWorkplace, the concept of <strong>Workspace</strong> exists, see that as a set of links which the user has access to, workspaces are secured by a Secunda task or EU Access right.
|
|
943
|
+
Same as the links, the workspaces are defined per environment in the <strong>workspaces</strong> folder, filename following this pattern : <strong>workspace-defs-base-ENV.json</strong></p>
|
|
944
|
+
<p>Here is the common workspace defition : </p>
|
|
945
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
946
|
+
"id": "WORKSPACE_ID (unique)",
|
|
947
|
+
"active": true,
|
|
948
|
+
"homeUrl": "/home",
|
|
949
|
+
"name": "Label of the workspace",
|
|
950
|
+
"description": "Description of the workspace",
|
|
951
|
+
"allowedRightIds": [
|
|
952
|
+
"MWP_ACCESS_WORKSPACE_SECUNDA_TASK"
|
|
953
|
+
],
|
|
954
|
+
"widgets": [
|
|
955
|
+
Workspace define here what are the home / dashboard widget that should be active by default
|
|
956
|
+
],
|
|
957
|
+
"baseLinkDefs": [
|
|
958
|
+
{
|
|
959
|
+
"id": "WORKSPACE-dashboard",
|
|
960
|
+
"url": "/home"
|
|
961
|
+
},
|
|
962
|
+
{
|
|
963
|
+
"id": "menu link ID as defined in the routes-defs-base-link-ENV.json for a particular menu link entry"
|
|
964
|
+
},
|
|
965
|
+
// here some common links are set for common MyWorkplace shell components
|
|
966
|
+
{
|
|
967
|
+
"id": "contact-us"
|
|
968
|
+
},
|
|
969
|
+
{
|
|
970
|
+
"id": "about"
|
|
971
|
+
},
|
|
972
|
+
{
|
|
973
|
+
"id": "welcome-doc"
|
|
974
|
+
}
|
|
975
|
+
]
|
|
976
|
+
}</code></pre></div><p>For workspace setup, please contact MWP team / DIGIT.A.4, we'll help you setting up based on your requirements, ensuring also the Secunda task for the user to have access to the workspace are setup correctly.</p>
|
|
977
|
+
<hr>
|
|
978
|
+
<hr>
|
|
979
|
+
<h2>Developing your micro-frontend</h2>
|
|
980
|
+
<h3>Feature branching - Jira flow</h3>
|
|
981
|
+
<p>Once your UI package has been created, your local environment setup, the host playground running fine with your raw skeleton UI package initialized locally, it's time to develop your features on top.</p>
|
|
982
|
+
<ol>
|
|
983
|
+
<li><p>In gitlab within the UI package repository created, create a new feature branch over the <strong>develop</strong> branch.</p>
|
|
984
|
+
</li>
|
|
985
|
+
<li><p>Checkout this feature branch in the <strong>./packages/YOUR_PACKAGE</strong> local folder/repository</p>
|
|
986
|
+
</li>
|
|
987
|
+
</ol>
|
|
988
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">cd packages/YOUR_PACKAGE
|
|
989
|
+
git fetch
|
|
990
|
+
git checkout feat/JIRA-KEY-new-amazing-feature</code></pre></div><ol start="3">
|
|
991
|
+
<li><p>Develop your feature / updates of the package / commit (using conventional commit msg format) and push on your feature branch, iterate</p>
|
|
992
|
+
</li>
|
|
993
|
+
<li><p>Build your package locally before the CI phase, in order to pre-check if your code is building fine, assuring that what you're building locally will run smoothly when the CI pipeline will build your package code.</p>
|
|
994
|
+
</li>
|
|
995
|
+
</ol>
|
|
996
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:build PKG_NAME</code></pre></div><h3>Adjusting the section / UI package route (after the default setup)</h3>
|
|
997
|
+
<p><a href="#routes-configuration">check the routes configuration chapter here</a>:</p>
|
|
998
|
+
<h3>Serving your UI code locally</h3>
|
|
999
|
+
<p>First "phase" of development is usually against the mock-server, although this can be kept and maintained forever in your development lifecycle,
|
|
1000
|
+
as it makes the UI development independent from the backend side (where DEV can be unstable as the backend team is also developing their services and are releasing on DEV often too).</p>
|
|
1001
|
+
<p>Each of the portal / host are coming with a playground script to run the API mock-server locally :</p>
|
|
1002
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run portalName-pl:start-mock</code></pre></div><p>for MyWorkplace :</p>
|
|
1003
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run mywp-pl:start-mock</code></pre></div><p>Second "phase" of development, you connect with the backend, this requires some additional steps out of the scope of this document, basically you would need to register your backend API on CAPI first, afterwards, you can check the <a href="#api-configuration">API configuration</a></p>
|
|
1004
|
+
<p>The playground host contains usually one or 2 scripts to proxy to DEV environment from your host playground served in your localhost,</p>
|
|
1005
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run portalName-pl:start-cdn-dev-local
|
|
1006
|
+
npm run portalName-pl:start-cdn-tst-local</code></pre></div><p>for MyWorkplace :</p>
|
|
1007
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run mywp-pl:start-cdn-dev-local
|
|
1008
|
+
npm run mywp-pl:start-cdn-tst-local</code></pre></div><p>Once you serve your host playground locally, the API calls will be against the ones that are deployed in the your DEV environment, obviously this will work if the host has already been released into a DEV environment, API configuration setup and backend APIs already deployed in DEV too.</p>
|
|
1009
|
+
<h3>Initializing a remote - serving it locally</h3>
|
|
1010
|
+
<p>This is optional and can be use to debug the remote locally, the same way as it'll be loaded on the server, with the same dependencies installed as it'll be running in the DEV environment.</p>
|
|
1011
|
+
<p><strong>Remark to consider</strong>
|
|
1012
|
+
The introduction of remotes made available the delivery of independent built sections and participants within the new architecture of mywp. This is a great feature when it comes to deliver independent built code, but it is far from being ideal in terms of local development: working directly on remotes is totally not ideal. Therefore we strongly recommend to use the standard lazy-loading mechanism to locally develop new business features related to sections / participants.</p>
|
|
1013
|
+
<p>For the majority of cases when something works with the lazy-loading mechanism, it also works once deployed as a remote. Unfortunately, there are cases when this doesn't happen and debugging the remote is necessary.</p>
|
|
1014
|
+
<p>Typically, this is the case when the skeleton is not ok. In such cases, we strongly recommend to check carefully the skeleton and locally debug the remote. Feel also free to get in contact with mywp team.</p>
|
|
1015
|
+
<h4>Initializing the remote</h4>
|
|
1016
|
+
<p>Same as for package, init command is used :</p>
|
|
1017
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --remote REMOTE_NAME</code></pre></div><p>This will result of a remote being initialized with the <strong>remotes</strong> root folder of your local project : <strong>/remotes/REMOTE_NAME</strong>
|
|
1018
|
+
In the end the dependencies are installed in its own "node_modules", as the remote is independent it only relies on its own dependencies installed,
|
|
1019
|
+
those are different from the ones installed when you're serving the MWP Playground itself,</p>
|
|
1020
|
+
<p>IMPORTANT : when serving the remote, you'll not serve the local sources of the root UI package wrapped, you'll serve the remote as it'll be delivered in a real environment...</p>
|
|
1021
|
+
<h4>Serving the remote locally</h4>
|
|
1022
|
+
<p>In order to achieve this, you need to instruct the remote to be serve and target the MWP playground, you can achieve this using that command :
|
|
1023
|
+
For the example we'll serve/build the remote : mywp-dashboard-remote-eui21 against MyWorkplace playground, the result would be that the remote distribution files / bundle will be copied to the <strong>hosts/my-workplace-host-playground/assets/elements/mywp-dashboard-remote-eui21</strong> folder, the serve here just builds the remote and transfer the build result (dist folder) into the host playground to be able for it to load the remote once the host will be served.</p>
|
|
1024
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run remote:serve mywp-dashboard-remote-eui21 -- --host my-workplace-host-playground</code></pre></div><p>Replace the remote here by your own as known in the <strong>csdr-config</strong> remote folder and the host by your own host playground name.</p>
|
|
1025
|
+
<h4>Activate the remote route</h4>
|
|
1026
|
+
<p>By default, the host playground is loading your "lazy" UI package when a route is hit once served (see routes configuration for more details).</p>
|
|
1027
|
+
<p>In order to bypass this lazy loaded routes (loading your UI package sources locally), and load the remote itself, we need to adapt the routes definitions,</p>
|
|
1028
|
+
<p>in our example here, we'll serve MyWorkplace playground against AWS CDN-DEV, and in order to achieve this we need to set the remote route for our remote into this file : route-defs.cdn-dev-local.json</p>
|
|
1029
|
+
<p>You'll see that by default it's an empty array, let's add our remote route definition, in our case the "mywp-dashboard" remote is associated with the "home" path in MyWorkplace :</p>
|
|
1030
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">[
|
|
1031
|
+
{
|
|
1032
|
+
"path": "home",
|
|
1033
|
+
"remote": true,
|
|
1034
|
+
"euiVersion": "21.x"
|
|
1035
|
+
}
|
|
1036
|
+
]</code></pre></div><h4>Serving the host</h4>
|
|
1037
|
+
<p>The last step you need is just serving the host, with its default command :</p>
|
|
1038
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run mywp-pl:start-cdn-dev-local</code></pre></div><p>Once you'll navigate to the route of the remote you want to debug/serve locally, the locally built/served remote will be loaded instead of the lazy loaded module of your local package sources.</p>
|
|
1039
|
+
<hr>
|
|
1040
|
+
<hr>
|
|
1041
|
+
<h2>Working with participant remote - local development and delivery</h2>
|
|
1042
|
+
<p>Before starting the process, it's very important to check the following pages:</p>
|
|
1043
|
+
<p><a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/display/CCTASK/Blocks%2C+Participants+and+layout">https://citnet.tech.ec.europa.eu/CITnet/confluence/display/CCTASK/Blocks%2C+Participants+and+layout</a>
|
|
1044
|
+
<a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/pages/viewpage.action?pageId=911078849">https://citnet.tech.ec.europa.eu/CITnet/confluence/pages/viewpage.action?pageId=911078849</a>
|
|
1045
|
+
<a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/display/COMPCORP/02+-+Micro-frontend+architecture+overview">https://citnet.tech.ec.europa.eu/CITnet/confluence/display/COMPCORP/02+-+Micro-frontend+architecture+overview</a></p>
|
|
1046
|
+
<ol>
|
|
1047
|
+
<li>Reference example</li>
|
|
1048
|
+
</ol>
|
|
1049
|
+
<p>In general, the reference example for anyone interested in this process is <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-task-actions-ui">cc-task-actions-ui</a> where the skeleton-config is defined in <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-config/-/tree/master/remotes?ref_type=heads">csdr-config</a> and the skeleton code derives from <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-config/-/blob/master/remotes/.euirc-remotes.json?ref_type=heads">euirc-remotes.json</a> (based on the following logic <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-engine/-/blob/master/resources/remotes.md?ref_type=heads">csdr-engine/remotes.md</a>).</p>
|
|
1050
|
+
<ol start="2">
|
|
1051
|
+
<li>Mywp host-playground setup and common commands</li>
|
|
1052
|
+
</ol>
|
|
1053
|
+
<p>setup : <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-root">mywp playground setup</a></p>
|
|
1054
|
+
<p>important commands: <a href="#annex-csdr-commands">common CSDR commands</a></p>
|
|
1055
|
+
<ol start="3">
|
|
1056
|
+
<li>Preliminary steps on the participant
|
|
1057
|
+
First of all, a request for creating a new dedicated ui-package for a participant together with its build plan should be sent to mywp support (with the indication of a meaningful name).</li>
|
|
1058
|
+
</ol>
|
|
1059
|
+
<p>As mentioned in <a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/display/CCTASK/Blocks%2C+Participants+and+layout">Blocks, Participants and layout</a>, a participant-block is simply an ng-component having an input called block. Once the dedicated ui package is available, a main ng-component should be created and exported in index.ts.</p>
|
|
1060
|
+
<p><strong>YourParticipant (dev branch)</strong></p>
|
|
1061
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">// index.ts
|
|
1062
|
+
export { YourParticipantComponent } from './path_to/your-participant.component';
|
|
1063
|
+
|
|
1064
|
+
// your-participant.component.ts
|
|
1065
|
+
import { Component, input } from '@angular/core';
|
|
1066
|
+
|
|
1067
|
+
import { ParticipantBlock } from '@cc/shared/block';
|
|
1068
|
+
|
|
1069
|
+
@Component({ ... })
|
|
1070
|
+
export class YourParticipantComponent {
|
|
1071
|
+
readonly block = input.required<YourParticipantBlock>();
|
|
1072
|
+
}</code></pre></div><p>Once the code is adapted, make sure to release your package on both dev and master.</p>
|
|
1073
|
+
<ol start="4">
|
|
1074
|
+
<li>Local development (integration with cc-participant-ui)
|
|
1075
|
+
First of all, make sure to locally add the following packages: <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-shared-ui">cc-shared-ui</a>, <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-task-details-ui">cc-task-details-ui</a> and <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-participants-ui">cc-participants-ui</a>. For local development, you need to make 3 PRs. First, send a PR for cc-participants-ui / dev where you add your <a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/display/CCTASK/Blocks%2C+Participants+and+layout">participant type</a> and some mandatory metadata.</li>
|
|
1076
|
+
</ol>
|
|
1077
|
+
<p><strong>cc-participants-ui (dev branch)</strong></p>
|
|
1078
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">// cc-participants-ui / integration / index.ts
|
|
1079
|
+
|
|
1080
|
+
export class ParticipantBlockType {
|
|
1081
|
+
|
|
1082
|
+
// your business name
|
|
1083
|
+
static YourUniqueParticipantType = 'your_unique_participant_type';
|
|
1084
|
+
}
|
|
1085
|
+
|
|
1086
|
+
export const PARTICIPANTS_METADATA: Record<string, { component: unknown }> = {
|
|
1087
|
+
|
|
1088
|
+
// your business name
|
|
1089
|
+
[ParticipantBlockType.YourUniqueParticipantType] = { component: undefined };
|
|
1090
|
+
}</code></pre></div><p>Second, send a PR for mywp-host-ui where you <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-host-ui/-/blob/master/assets/19.x/app-root-playground/dependencies-composite.json">add your participant package as a dep of the host playground</a>. Finally, make a PR to <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-participants-ui/-/blob/feat/local-dev-v19/integration/index.ts">cc-participants-ui / feat / local-dev-v19</a> with the changes above and the ones necessary to enable local development on your participant (local development = flip cc-participants-ui to feat/local-dev-v19).</p>
|
|
1091
|
+
<p><strong>cc-participants-ui integration (feat / local-dev-v19 branch)</strong></p>
|
|
1092
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">// cc-participants-ui / integration / index.ts
|
|
1093
|
+
|
|
1094
|
+
import { YourParticipantComponent } from '@cc/your-participant';
|
|
1095
|
+
|
|
1096
|
+
export class ParticipantBlockType {
|
|
1097
|
+
|
|
1098
|
+
// your business name
|
|
1099
|
+
static YourUniqueParticipantType = 'your_unique_participant_type';
|
|
1100
|
+
}
|
|
1101
|
+
|
|
1102
|
+
export const PARTICIPANTS_METADATA: Record<string, { component: unknown }> = {
|
|
1103
|
+
|
|
1104
|
+
// your business name
|
|
1105
|
+
[ParticipantBlockType.YourUniqueParticipantType] = { component: YourParticipantComponent };
|
|
1106
|
+
}</code></pre></div><ol start="5">
|
|
1107
|
+
<li>Remote package: creation and setup
|
|
1108
|
+
A request for creating a DEV and TST plan for the delivery of a participant remote in mywp must be sent to mywp support. The request should provide some relevant metadata equivalent to the one in <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-config/-/blob/master/remotes/.euirc-remotes.json?ref_type=heads">csdr-config / remotes / .euirc-remotes.json#cc-task-actions-eui19-remote-el-ui</a>. The name of the plan will be based on your main package name.</li>
|
|
1109
|
+
</ol>
|
|
1110
|
+
<p><strong>remote metadata</strong></p>
|
|
1111
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"cc-your-participant-eui19-remote-el-ui": {
|
|
1112
|
+
...
|
|
1113
|
+
"fullSkeletonSources": true,
|
|
1114
|
+
"standaloneSkeleton": true,
|
|
1115
|
+
"standaloneParticipant": true,
|
|
1116
|
+
|
|
1117
|
+
"skeletonConfig": {
|
|
1118
|
+
|
|
1119
|
+
// name of your participant package
|
|
1120
|
+
"rootNpmPkg": "@cc/your-participant",
|
|
1121
|
+
|
|
1122
|
+
// name of the main component exported in your participant package
|
|
1123
|
+
"rootComponent": "YourEntryParticipant",
|
|
1124
|
+
|
|
1125
|
+
// tag for the custom element: it must be unique
|
|
1126
|
+
"elementName": "cc-your-participant-v19,
|
|
1127
|
+
|
|
1128
|
+
// options
|
|
1129
|
+
"options": {
|
|
1130
|
+
"zoneless": true
|
|
1131
|
+
}
|
|
1132
|
+
}
|
|
1133
|
+
},</code></pre></div><p>In case of issues, check <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-engine/-/blob/master/resources/remotes.md?ref_type=heads">csdr-engine/remotes.md</a> or reach out mywp team for help.</p>
|
|
1134
|
+
<ol start="6">
|
|
1135
|
+
<li>Remote delivery in dev - tst
|
|
1136
|
+
In order to make the delivery of a remote effective in dev - tst, you first need to successfully release the remote in such environments. Once the delivery is done, you need to properly configure task-details in order to load your remote: simply edit any relevant <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-config">openid-login-config.{env}.json</a> file at remotes entry and make a PR with the changes.</li>
|
|
1137
|
+
</ol>
|
|
1138
|
+
<p><strong>openid-login-config.{env}.json configuration</strong></p>
|
|
1139
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"remotes": {
|
|
1140
|
+
...
|
|
1141
|
+
"your_unique_participant_type": {
|
|
1142
|
+
"moduleId": "cc-your-participant-eui19-remote-el-ui", // entry in csdr-config
|
|
1143
|
+
"elementTag": "cc-your-participant-v19" // match of tag-name in csdr-config
|
|
1144
|
+
},
|
|
1145
|
+
...
|
|
1146
|
+
}</code></pre></div><p>Once the config is updated, make sure to release mywp-host in the relevant environments. Assuming everything went well, you'll be able to see your remote loading in task-details for properly configured tasks at task-detail level.</p>
|
|
1147
|
+
<ol start="7">
|
|
1148
|
+
<li>Debugging of remote issues
|
|
1149
|
+
The introduction of remotes made available the delivery of independent built sections and participants within the new architecture of mywp. This is a great feature when it comes to deliver independent built code, but it is far from ideal in terms of local development: working directly with remotes is difficult. Therefore we strongly recommend to use the standard lazy-loading mechanism to locally develop new business features related to sections / participants.</li>
|
|
1150
|
+
</ol>
|
|
1151
|
+
<p>Assuming you followed all the steps in the "Integration with cc-participant-ui", setting up your local environment to achieve that is as simple as:</p>
|
|
1152
|
+
<ul>
|
|
1153
|
+
<li>moving to <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-participants-ui/-/blob/feat/local-dev-v19">cc-participants-ui / feat / local-dev-v19</a>,</li>
|
|
1154
|
+
<li>sync,</li>
|
|
1155
|
+
<li>serve mywp-host-playground.
|
|
1156
|
+
In the majority of cases when something works with the lazy-loading mechanism, it also works once deployed as a remote. Unfortunately, there are cases when this doesn't happen and locally debugging the remote is necessary. Typically, this is the case when the skeleton is not ok.</li>
|
|
1157
|
+
</ul>
|
|
1158
|
+
<p>To achieve that, you have to locally</p>
|
|
1159
|
+
<ul>
|
|
1160
|
+
<li>init the remote,</li>
|
|
1161
|
+
<li>serve the remote,</li>
|
|
1162
|
+
<li>tweak the relevant openid-login-config.{local-env}.json as described in "Remote delivery in dev - tst",</li>
|
|
1163
|
+
<li>serve the host,</li>
|
|
1164
|
+
<li>debug the code in .../assets/elements/your-participant-eui19-remote-el-ui/bundles/main.js</li>
|
|
1165
|
+
</ul>
|
|
1166
|
+
<p>Note: the code a remote is built upon is coming from its own node-modules. This implies there is no live-reload available for remotes when you want to test some changes: you need to release all packages, sync and serve the remote again.</p>
|
|
1167
|
+
<p>In cases something is not really clear, feel also free to get in contact with mywp team.</p>
|
|
1168
|
+
<hr>
|
|
1169
|
+
<hr>
|
|
1170
|
+
<h2>Releasing your micro-frontend</h2>
|
|
1171
|
+
<h3>Overview</h3>
|
|
1172
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-mermaid">sequenceDiagram
|
|
1173
|
+
autonumber
|
|
1174
|
+
participant Local as CSDR Local env.
|
|
1175
|
+
participant UIPkg as UI package repo
|
|
1176
|
+
participant HostUI as mywp-host-ui repo
|
|
1177
|
+
participant Mock as mwp mock repo
|
|
1178
|
+
participant Config as mwp config repo
|
|
1179
|
+
participant CI as CI Gitlab
|
|
1180
|
+
participant Nexus as NEXUS / Servers
|
|
1181
|
+
|
|
1182
|
+
Note over Local: [1] MWP host playground setup
|
|
1183
|
+
|
|
1184
|
+
rect rgb(240, 240, 240)
|
|
1185
|
+
Note right of HostUI: [2] Create feature branch (master)
|
|
1186
|
+
HostUI-->>Local: [2'] Declare pkg lib / Create routes
|
|
1187
|
+
end
|
|
1188
|
+
|
|
1189
|
+
rect rgb(200, 255, 255)
|
|
1190
|
+
Note right of UIPkg: [3] Create feature branch (develop)
|
|
1191
|
+
UIPkg-->>Local: [3'] Develop UI package
|
|
1192
|
+
end
|
|
1193
|
+
|
|
1194
|
+
rect rgb(240, 240, 240)
|
|
1195
|
+
Note right of Mock: [4] Create feature branch (master)
|
|
1196
|
+
Mock-->>Local: [4'] Create mock entries (optional)
|
|
1197
|
+
Note right of Config: [5] Create feature branch (master)
|
|
1198
|
+
Config-->>Local: [5'] Create OpenID entries
|
|
1199
|
+
end
|
|
1200
|
+
|
|
1201
|
+
Note over UIPkg: [3''] PR feature to develop
|
|
1202
|
+
UIPkg->>CI: [3r] Build UI PKG (develop)
|
|
1203
|
+
CI->>Nexus: x.y.z-SNP
|
|
1204
|
+
|
|
1205
|
+
Note over HostUI: [2''] PR feature to master
|
|
1206
|
+
HostUI->>CI: [2r] Build PKG master
|
|
1207
|
+
CI->>Nexus: x.y.z
|
|
1208
|
+
|
|
1209
|
+
Note over Config: [5''] PR feature to master
|
|
1210
|
+
Config->>CI: [5r] Build PKG master
|
|
1211
|
+
CI->>Nexus: x.y.z
|
|
1212
|
+
|
|
1213
|
+
CI->>Nexus: [6r] REMOTE DEV BUILD (x.y.z.SNP.n)
|
|
1214
|
+
|
|
1215
|
+
Note over UIPkg: [7] PR develop to master
|
|
1216
|
+
UIPkg->>CI: [7r] Build UI PKG master
|
|
1217
|
+
CI->>Nexus: x.y.z
|
|
1218
|
+
|
|
1219
|
+
CI->>Nexus: [8r] REMOTE TST BUILD (x.y.z.TST.n)
|
|
1220
|
+
</code></pre></div><p>This document outlines the end-to-end lifecycle of a micro-frontend, from local setup to remote environment deployment.</p>
|
|
1221
|
+
<h4>Legend</h4>
|
|
1222
|
+
<ul>
|
|
1223
|
+
<li><strong>[1] Blue Square</strong>: One-time setup tasks.</li>
|
|
1224
|
+
<li><strong>[2] Blue Square</strong>: Optional tasks.</li>
|
|
1225
|
+
<li><strong>[3] Teal Square</strong>: Day-to-day development tasks.</li>
|
|
1226
|
+
<li><strong>[#'] Prime</strong>: Local environment configuration/entry.</li>
|
|
1227
|
+
<li><strong>[#r] 'r' suffix</strong>: CI/CD Pipeline / Build tasks.</li>
|
|
1228
|
+
</ul>
|
|
1229
|
+
<hr>
|
|
1230
|
+
<h4>1. Local Environment & Repository Setup</h4>
|
|
1231
|
+
<table class="table table-bordered compodoc-table">
|
|
1232
|
+
<thead>
|
|
1233
|
+
<tr>
|
|
1234
|
+
<th align="left">Step</th>
|
|
1235
|
+
<th align="left">Action</th>
|
|
1236
|
+
<th align="left">Repository/Scope</th>
|
|
1237
|
+
<th align="left">Type</th>
|
|
1238
|
+
</tr>
|
|
1239
|
+
</thead>
|
|
1240
|
+
<tbody>
|
|
1241
|
+
<tr>
|
|
1242
|
+
<td align="left"><strong>1</strong></td>
|
|
1243
|
+
<td align="left">MWP host playground setup</td>
|
|
1244
|
+
<td align="left"><strong>CSDR Local env.</strong></td>
|
|
1245
|
+
<td align="left">One-time</td>
|
|
1246
|
+
</tr>
|
|
1247
|
+
<tr>
|
|
1248
|
+
<td align="left"><strong>2</strong></td>
|
|
1249
|
+
<td align="left">Create feature branch from master</td>
|
|
1250
|
+
<td align="left"><strong>mywp-host-ui repo</strong></td>
|
|
1251
|
+
<td align="left">Development</td>
|
|
1252
|
+
</tr>
|
|
1253
|
+
<tr>
|
|
1254
|
+
<td align="left"><strong>2'</strong></td>
|
|
1255
|
+
<td align="left">Create route entries & Declare pkg lib</td>
|
|
1256
|
+
<td align="left"><strong>CSDR Local env.</strong></td>
|
|
1257
|
+
<td align="left">Configuration</td>
|
|
1258
|
+
</tr>
|
|
1259
|
+
<tr>
|
|
1260
|
+
<td align="left"><strong>3</strong></td>
|
|
1261
|
+
<td align="left">Create feature branch from develop</td>
|
|
1262
|
+
<td align="left"><strong>UI package repo</strong></td>
|
|
1263
|
+
<td align="left">Day-to-day</td>
|
|
1264
|
+
</tr>
|
|
1265
|
+
<tr>
|
|
1266
|
+
<td align="left"><strong>4</strong></td>
|
|
1267
|
+
<td align="left">Create feature branch from master</td>
|
|
1268
|
+
<td align="left"><strong>mwp mock repo</strong></td>
|
|
1269
|
+
<td align="left">Optional</td>
|
|
1270
|
+
</tr>
|
|
1271
|
+
<tr>
|
|
1272
|
+
<td align="left"><strong>5</strong></td>
|
|
1273
|
+
<td align="left">Create feature branch from master</td>
|
|
1274
|
+
<td align="left"><strong>mwp config repo</strong></td>
|
|
1275
|
+
<td align="left">Configuration</td>
|
|
1276
|
+
</tr>
|
|
1277
|
+
</tbody>
|
|
1278
|
+
</table>
|
|
1279
|
+
<hr>
|
|
1280
|
+
<h4>2. Development Phase (Day-to-Day)</h4>
|
|
1281
|
+
<ol>
|
|
1282
|
+
<li><strong>Develop UI package [3']</strong>: Conducted in the <code>CSDR Local env.</code> on the local feature branch.</li>
|
|
1283
|
+
<li><strong>Mocking (Optional) [4']</strong>: Create mock entries in <code>mywp-mock</code> to support UI development.</li>
|
|
1284
|
+
<li><strong>Config [5']</strong>: Create OpenID entries in <code>mywp-cconfig</code>.</li>
|
|
1285
|
+
<li><strong>Integration [3'']</strong>: Pull Request (PR) from the feature branch to the <code>develop</code> branch in the <strong>UI package repo</strong>.</li>
|
|
1286
|
+
</ol>
|
|
1287
|
+
<hr>
|
|
1288
|
+
<h4>3. CI/CD & Build Pipeline (Bamboo/CSDR)</h4>
|
|
1289
|
+
<h4>Stage A: Development & Snapshot Builds</h4>
|
|
1290
|
+
<ul>
|
|
1291
|
+
<li><strong>Build UI PKG develop [3r]</strong>: Triggered by PR to develop.<ul>
|
|
1292
|
+
<li><em>Result:</em> Generates <code>x.y.z-SNP</code> artifact in Nexus.</li>
|
|
1293
|
+
</ul>
|
|
1294
|
+
</li>
|
|
1295
|
+
<li><strong>PR to Master [2'']</strong>: Move host changes from feature to master in <code>mywp-host-ui</code>.</li>
|
|
1296
|
+
<li><strong>Build PKG master [2r]</strong>: Builds the host application.<ul>
|
|
1297
|
+
<li><em>Result:</em> Generates <code>x.y.z</code> artifact in Nexus.</li>
|
|
1298
|
+
</ul>
|
|
1299
|
+
</li>
|
|
1300
|
+
<li><strong>Remote Dev Build [6r]</strong>: Deploys the snapshot to the dev server.<ul>
|
|
1301
|
+
<li><em>Endpoint:</em> <code>x.y.z. SNP.n</code></li>
|
|
1302
|
+
</ul>
|
|
1303
|
+
</li>
|
|
1304
|
+
</ul>
|
|
1305
|
+
<h4>Stage B: Release & Test Builds</h4>
|
|
1306
|
+
<ul>
|
|
1307
|
+
<li><strong>Config PR [5'']</strong>: Merge config changes to master in <code>mwp config repo</code>.</li>
|
|
1308
|
+
<li><strong>Config Build [5r]</strong>: Builds the configuration package.</li>
|
|
1309
|
+
<li><strong>Promote UI [7]</strong>: PR from <code>develop</code> to <code>master</code> in the <strong>UI package repo</strong>.</li>
|
|
1310
|
+
<li><strong>Final UI Build [7r]</strong>: Builds the master branch of the UI package.<ul>
|
|
1311
|
+
<li><em>Result:</em> Generates stable <code>x.y.z</code> artifact in Nexus.</li>
|
|
1312
|
+
</ul>
|
|
1313
|
+
</li>
|
|
1314
|
+
<li><strong>Remote Test Build [8r]</strong>: Final deployment to the TST environment.<ul>
|
|
1315
|
+
<li><em>Endpoint:</em> <code>x.y.z.TST.n</code></li>
|
|
1316
|
+
</ul>
|
|
1317
|
+
</li>
|
|
1318
|
+
</ul>
|
|
1319
|
+
<hr>
|
|
1320
|
+
<h4>4. Environment & Artifact Mapping</h4>
|
|
1321
|
+
<table class="table table-bordered compodoc-table">
|
|
1322
|
+
<thead>
|
|
1323
|
+
<tr>
|
|
1324
|
+
<th align="left">Environment</th>
|
|
1325
|
+
<th align="left">Artifact Versioning</th>
|
|
1326
|
+
<th align="left">Target Server</th>
|
|
1327
|
+
</tr>
|
|
1328
|
+
</thead>
|
|
1329
|
+
<tbody>
|
|
1330
|
+
<tr>
|
|
1331
|
+
<td align="left"><strong>Nexus (Dev)</strong></td>
|
|
1332
|
+
<td align="left"><code>x.y.z-SNP</code></td>
|
|
1333
|
+
<td align="left">Development Storage</td>
|
|
1334
|
+
</tr>
|
|
1335
|
+
<tr>
|
|
1336
|
+
<td align="left"><strong>Nexus (Prod/Test)</strong></td>
|
|
1337
|
+
<td align="left"><code>x.y.z</code></td>
|
|
1338
|
+
<td align="left">Release Storage</td>
|
|
1339
|
+
</tr>
|
|
1340
|
+
<tr>
|
|
1341
|
+
<td align="left"><strong>Remote DEV</strong></td>
|
|
1342
|
+
<td align="left"><code>x.y.z. SNP.n</code></td>
|
|
1343
|
+
<td align="left">Dev Server</td>
|
|
1344
|
+
</tr>
|
|
1345
|
+
<tr>
|
|
1346
|
+
<td align="left"><strong>Remote TST</strong></td>
|
|
1347
|
+
<td align="left"><code>x.y.z.TST.n</code></td>
|
|
1348
|
+
<td align="left">Test Server</td>
|
|
1349
|
+
</tr>
|
|
1350
|
+
</tbody>
|
|
1351
|
+
</table>
|
|
1352
|
+
<hr>
|
|
1353
|
+
<h3>Releasing to DEV environment</h3>
|
|
1354
|
+
<p>In the Micro-Frontend architecture that CSDR/BAEP embed, you don't deliver a monolith application globally, you're delivering chunks of it, here the micro-frontends, or <strong>remotes</strong> and <strong>host</strong>.</p>
|
|
1355
|
+
<p>The <strong>remote</strong> is always linked to a <strong>UI package</strong> which contains the sources of your business code you want to ship into environments, which is stored in a git repository at the difference of the <strong>remotes</strong> themselves which are generated based on configuration.</p>
|
|
1356
|
+
<p>The git operations are exclusively made on those <strong>UI packages</strong> you're in control and have their own repositories in Gitlab, together with their branching and their versioning / tagged in the repository itself after each <strong>master</strong> release.</p>
|
|
1357
|
+
<h4>1. UI Package : from feature branch to develop, snapshot package release</h4>
|
|
1358
|
+
<ol>
|
|
1359
|
+
<li><p>Once your code is ready to be shipped to the first environment : <strong>DEV</strong>, those steps are usually used :</p>
|
|
1360
|
+
</li>
|
|
1361
|
+
<li><p>Run the package build pipeline locally</p>
|
|
1362
|
+
</li>
|
|
1363
|
+
</ol>
|
|
1364
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:build YOUR_PACKAGE</code></pre></div><ol start="5">
|
|
1365
|
+
<li><p>Once ready to be built on gitlab CI side (so from the develop branch), pull request and merge the feature branch you're working on to the <strong>develop</strong> branch</p>
|
|
1366
|
+
</li>
|
|
1367
|
+
<li><p>The package is now building gitlab CI side and if everything goes well a <strong>snapshot</strong> version of the package is published, the output of the CI pipeline is sent to the MS teams channel associated with your package.</p>
|
|
1368
|
+
</li>
|
|
1369
|
+
</ol>
|
|
1370
|
+
<h4>2. Remote in DEV build and publication</h4>
|
|
1371
|
+
<p>The UI package alone is not distributed, that's the role of the <strong>remote</strong> wrapping and depending on the <strong>UI package dependency</strong>, let's deliver the remote :</p>
|
|
1372
|
+
<p>Once a <strong>snapshot</strong> of the package has been successfully built, it's time to deploy the remote / micro-frontend associated with your UI package :</p>
|
|
1373
|
+
<ol>
|
|
1374
|
+
<li>Build the associated remote of your package with an <strong>env_target='dev'</strong> (default)</li>
|
|
1375
|
+
</ol>
|
|
1376
|
+
<ul>
|
|
1377
|
+
<li>on the repository trigger of the remote : your-package-remote-eui21 (f.e.) => pipelines => new pipeline => leave the env_target='dev' => new pipeline</li>
|
|
1378
|
+
</ul>
|
|
1379
|
+
<ol start="2">
|
|
1380
|
+
<li>Inspect the result of the CI output in the MS Teams channel associated with your remote, if successful, the remote is now published in the DEV environment, the <strong>remote</strong> is pushed to the <strong>S3 bucket</strong> configured for the <strong>DEV</strong> environment of the app, it is now available on the server.</li>
|
|
1381
|
+
</ol>
|
|
1382
|
+
<p>Iterate the UI package / develop branch and remote "dev" release until you're ready to ship in upper environments (TST until PROD).</p>
|
|
1383
|
+
<h3>Releasing to TST and upper environments</h3>
|
|
1384
|
+
<p>Once you've iterated on the DEV environment, it's time to push the remote up the environments, starting with the TST one.</p>
|
|
1385
|
+
<p>It's important to notice here that ONLY <strong>latest</strong> release of the UI package associated with the remote are released in TST and up, so from the <strong>master</strong> branch of your package (or an hotfix / support branch), the <strong>snapshot</strong> and <strong>next</strong> (or RC) releases of your packages will only be picked up by a remote targetted to the <strong>DEV</strong> environment.</p>
|
|
1386
|
+
<h4>1. UI package : from develop to master, latest package release</h4>
|
|
1387
|
+
<p>Let's release your package as <strong>latest</strong> version, so from the <strong>master</strong> branch of it :</p>
|
|
1388
|
+
<ol>
|
|
1389
|
+
<li><p>Pull request your <strong>develop</strong> branch to <strong>master</strong> on your UI package repository</p>
|
|
1390
|
+
</li>
|
|
1391
|
+
<li><p>Once merged, the CI pipeline will trigger a master branch release / and will publish upon successful completion a <strong>latest</strong> release of your package, package will be <strong>tagged</strong>, the version will now be the production version of your package : <strong>x.m.p</strong> where "x" is the current major version of your package, "m" is the sequence of the minor semantic release - "p" is the patch number, this semantic version is influenced by the list of commits since last tag of your package, if you've done a "feat:" commit, the minor sequence "m" will be increased, if a "chore: or fix:", the patch sequence "p" will be increased.</p>
|
|
1392
|
+
</li>
|
|
1393
|
+
</ol>
|
|
1394
|
+
<h4>2. Remote in TST build and publication</h4>
|
|
1395
|
+
<p>Once the package has been released as a <strong>latest</strong> release, it's time to deploy the remote / micro-frontend associated with your UI package in the TST environment (or the environment that comes after TST in your environment sequence for your portal / host) :</p>
|
|
1396
|
+
<ol>
|
|
1397
|
+
<li>Build the associated remote of your package with an <strong>env_target='tst'</strong></li>
|
|
1398
|
+
</ol>
|
|
1399
|
+
<ul>
|
|
1400
|
+
<li>on the repository trigger of the remote : your-package-remote-eui21 (f.e.) => pipelines => new pipeline => leave the env_target='tst' => new pipeline</li>
|
|
1401
|
+
</ul>
|
|
1402
|
+
<ol start="2">
|
|
1403
|
+
<li>Inspect the result of the CI output in the MS Teams channel associated with your remote, if successful, the remote is now published in the TST environment, the <strong>remote</strong> is pushed to the <strong>S3 bucket</strong> configured for the <strong>TST</strong> environment of the app, it is now available on the server.</li>
|
|
1404
|
+
</ol>
|
|
1405
|
+
<h4>3. Upper environment release up to PROD</h4>
|
|
1406
|
+
<p>For delivering the remote after the <strong>TST</strong> environment, 2 cases :</p>
|
|
1407
|
+
<p><strong>BAEP portals / own release management operations</strong></p>
|
|
1408
|
+
<p>If you're developing your own portal / BAEP, you're in control to push the remotes and target the environement directly from the remote trigger repository, basically setting the <strong>env_target</strong> input of the pipeline to the targeted environment : tst,int,acc,ppd,prd,trn (for example).</p>
|
|
1409
|
+
<p><strong>MyWorkplace - controlled by Release management and by release orchestrator : XLRelease</strong></p>
|
|
1410
|
+
<p>For MyWorkplace, the development teams can deliver up to <strong>TST</strong> only, after that for all other environment in the sequence, they follow some additional control driven by the release managers in charge, <strong>INT</strong> and up have a dedicated Release management channel where the teams are posting their intention to release in upper environments.</p>
|
|
1411
|
+
<p>Note that the <strong>host</strong> delivery in upper envs in also the responsability of the MyWorkplace release management / QA team to respect the targeted / scheduled release train.</p>
|
|
1412
|
+
<p>(see next point for details about CSDR sequential release aspects)</p>
|
|
1413
|
+
<h4>CSDR sequential environment releases</h4>
|
|
1414
|
+
<p>!IMPORTANT : this describe the sequential release applied to ALL CSDR remotes / host, it's important to consider to avoid surprises once delivering</p>
|
|
1415
|
+
<p>Once a environment sequence has been setup (when your portal has been setup by support / changed by you afterwards), the sequence of delivery should be respected in order for the remote and the host to transit to each environment one-by-one in the sequence.</p>
|
|
1416
|
+
<p>Why is that mandatory ?</p>
|
|
1417
|
+
<p>Once a remote or host are built against specific dependencies set (in their respective dependencies-composite.json file), if on a targeted environment, the built is successful, the active set of dependencies versions is archived, the next environment in the sequence will reuse this known set of dependencies that the remote / host were build successfully against in the previous environment and re-use them for the next environment delivery, this ensuring that the same set is <strong>propagated</strong>, avoiding to have a version of a dependency in a higher environment that wasn't tested in a previous one.</p>
|
|
1418
|
+
<p>As we'll see this sequence can be overridden if we want to do an hotfix release of a specific version of a package in an higher environment.</p>
|
|
1419
|
+
<h5>Default environment sequence : TST dependencies to PROD</h5>
|
|
1420
|
+
<p>Example, we deliver a remote in a TST environment where the remote <strong>dependencies-composite.json</strong> or this remote is as follows:</p>
|
|
1421
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1422
|
+
"base:" {
|
|
1423
|
+
...
|
|
1424
|
+
},
|
|
1425
|
+
"composite": {
|
|
1426
|
+
"@eui/deps-base": "^21.0.0",
|
|
1427
|
+
"@csdr/core": "^9.0.0",
|
|
1428
|
+
"@csdr/integration": "^8.0.0",
|
|
1429
|
+
"@cc/workload": "^1.0.0"
|
|
1430
|
+
},
|
|
1431
|
+
"int": {},
|
|
1432
|
+
"acc": {},
|
|
1433
|
+
"dlt": {},
|
|
1434
|
+
"ppd": {},
|
|
1435
|
+
"prd": {},
|
|
1436
|
+
"trn": {}
|
|
1437
|
+
}</code></pre></div><p>Once built in TST the dependencies installed and <strong>composed</strong> will be (just an example):</p>
|
|
1438
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1439
|
+
"@eui/deps-base": "21.1.2",
|
|
1440
|
+
"@csdr/core": "9.0.1",
|
|
1441
|
+
"@csdr/integration": "8.0.2",
|
|
1442
|
+
"@cc/workload": "1.0.1"
|
|
1443
|
+
}</code></pre></div><p>The remote will be delivered in TST with this dependencies marked in the sequence.</p>
|
|
1444
|
+
<p>Once we'll deliver in the <strong>INT</strong> environment (next in the sequence), the <strong>composed</strong> dependencies will now take the marked dependencies that has been used / installed once the <strong>TST</strong> environment has been successfully built / delivered :</p>
|
|
1445
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1446
|
+
"@eui/deps-base": "21.1.2",
|
|
1447
|
+
"@csdr/core": "9.0.1",
|
|
1448
|
+
"@csdr/integration": "8.0.2",
|
|
1449
|
+
"@cc/workload": "1.0.1"
|
|
1450
|
+
}</code></pre></div><p>And so on until this set reaches the <strong>PROD</strong> environment.</p>
|
|
1451
|
+
<h5>Locked dependencies / override sequence for hotfix package fix version in upper environments</h5>
|
|
1452
|
+
<p>When an important patch needs to be delivered in an upper environment, for example <strong>PreProd</strong> or <strong>PROD</strong>, the default sequence can be bypassed, by <strong>locking</strong> a specific version of a package for a specific environment.</p>
|
|
1453
|
+
<p>This is also done through the <strong>dependencies-composite.json</strong> file of the remote, if we take the previous remote and we want to deliver a package release from its hotfix/ branch where an hotfix version of the package has already been built (see git branching hotfix section here under for more info), we just <strong>lock</strong> this particular version in the environment we need :</p>
|
|
1454
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1455
|
+
"base:" {
|
|
1456
|
+
...
|
|
1457
|
+
},
|
|
1458
|
+
"composite": {
|
|
1459
|
+
"@eui/deps-base": "^21.0.0",
|
|
1460
|
+
"@csdr/core": "^9.0.0",
|
|
1461
|
+
"@csdr/integration": "^8.0.0",
|
|
1462
|
+
"@cc/workload": "^1.0.0"
|
|
1463
|
+
},
|
|
1464
|
+
"int": {},
|
|
1465
|
+
"acc": {},
|
|
1466
|
+
"dlt": {},
|
|
1467
|
+
"ppd": {},
|
|
1468
|
+
"prd": {
|
|
1469
|
+
"@cc/workload": "1.0.1-1"
|
|
1470
|
+
},
|
|
1471
|
+
"trn": {}
|
|
1472
|
+
}</code></pre></div><p>Once here we'll deliver to <strong>PROD</strong>, the explicit version 1.0.1-1 of this package will be used, and not the one from the previous environment dependencies medata (PreProd) bypassing the default sequence.</p>
|
|
1473
|
+
<h5>Locked dependencies - à la carte release</h5>
|
|
1474
|
+
<p>It behaves the same as the locked for hotfix release, but in the case of <strong>à la carte</strong> you can lock your dependencies on every environment, this optional way of handling dependencies let's you control what goes where in each of the remote environment.</p>
|
|
1475
|
+
<p>If we take the example from above, here the result of <strong>locking</strong> a package in every environment, where the version is controlled :</p>
|
|
1476
|
+
<p>the <strong>1.0.5</strong> version of the package here is active in dev (with the latest or snapshot version of the package), in tst (latest version), in int / acc / dlt where this version is locked, while ppd, prd, and trn remains in an earlier version of the package.</p>
|
|
1477
|
+
<p>Note : use this if you want deeper control of your dependencies on each environment, although this creates overhead in your delivery, each time you want to release into an environment, the versions must be explicitely specified, you need to send pull request to the <strong>csdr-config</strong> repository, the release management role becomes more consequent (specially if he/she has to work with multiple remotes for his/her team).</p>
|
|
1478
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1479
|
+
"base:" {
|
|
1480
|
+
...
|
|
1481
|
+
},
|
|
1482
|
+
"composite": {
|
|
1483
|
+
"@eui/deps-base": "^21.0.0",
|
|
1484
|
+
"@csdr/core": "^9.0.0",
|
|
1485
|
+
"@csdr/integration": "^8.0.0",
|
|
1486
|
+
"@cc/workload": "^1.0.0"
|
|
1487
|
+
},
|
|
1488
|
+
"int": {
|
|
1489
|
+
"@cc/workload": "1.0.5"
|
|
1490
|
+
},
|
|
1491
|
+
"acc": {
|
|
1492
|
+
"@cc/workload": "1.0.5"
|
|
1493
|
+
},
|
|
1494
|
+
"dlt": {
|
|
1495
|
+
"@cc/workload": "1.0.5"
|
|
1496
|
+
},
|
|
1497
|
+
"ppd": {
|
|
1498
|
+
"@cc/workload": "1.0.1"
|
|
1499
|
+
},
|
|
1500
|
+
"prd": {
|
|
1501
|
+
"@cc/workload": "1.0.1"
|
|
1502
|
+
},
|
|
1503
|
+
"trn": {
|
|
1504
|
+
"@cc/workload": "1.0.1"
|
|
1505
|
+
}
|
|
1506
|
+
}</code></pre></div><hr>
|
|
1507
|
+
<hr>
|
|
1508
|
+
<h2>CSDR git branching</h2>
|
|
1509
|
+
<h3>Default develop to master release cycle</h3>
|
|
1510
|
+
<p>By default cloned repos (during initialization) you'll be working in your local are pointing to the <strong>develop</strong> branch of each repos, mainly here for the <strong>home-ui</strong> and <strong>shell-ui</strong> UI packages folder/repos in the <strong>/packages</strong> folder.</p>
|
|
1511
|
+
<p>In CSDR, the <strong>develop</strong> branch once pushed and released through the pipeline will generate a <strong>snapshot</strong> release of the UI package which can then be used as a dependency of the <strong>host</strong> or the <strong>remote</strong> targeting the publication on the <strong>DEV</strong> environment, the first environment in the sequence of distribution.</p>
|
|
1512
|
+
<p>Once the <strong>host</strong> and <strong>remote(s)</strong> are mature enough in the <strong>DEV</strong> environment, through an iteration cycle for example, the release manager or the developer is ready to ship the changes into the upper environments : first after <strong>DEV</strong> being the <strong>TST</strong> environment (in most sequence (default)).</p>
|
|
1513
|
+
<p>At this stage, developer is merging all necessary UI package from their <strong>develop</strong> branch to the <strong>master</strong> branch, once the pipeline is triggered and the UI package published, it will generate a <strong>latest</strong> release, this <strong>latest</strong> from master being <strong>tagged</strong> with a semantic version corresponding to the accumulated commits which happened from the previous <strong>master</strong> release of it.</p>
|
|
1514
|
+
<p>The UI package <strong>latest</strong> release version then can be used as a dependency of the <strong>host</strong> or <strong>remote</strong> for their distribution in <strong>TST</strong> and upper environments.</p>
|
|
1515
|
+
<h3>Hotfix release cycle : hotfix/ branch</h3>
|
|
1516
|
+
<h4>Setting up hotfix branch to deliver to higher environments</h4>
|
|
1517
|
+
<p>From a tagged release deliver in the PROD env f.e. or the latest master branch of the UI package delivered in acc/prd, you can generate a branch called <strong>hotfix/VERSION</strong> where the version is ideally the version of the tag you want to hotfix, from this branch the pipeline will generate an hotfix version : considering the version to fix is f.e. : x.y.z, the generated hotfix version will be : x.y.z-n (n being the sequence of the hotfix).</p>
|
|
1518
|
+
<h4>Locking the hotfix version in your remote dependencies for a specific environment</h4>
|
|
1519
|
+
<p>Once the hotfix version is generated you an <strong>lock</strong> the version in the <strong>dependencies.json</strong> of the remote in a particular environment : acc or prd f.e., when you'll build the remote targeting those environments, it will take the version <strong>locked</strong> from the hotfix release of the package you did.</p>
|
|
1520
|
+
<p>In this example we're <strong>locking</strong> the @baep/sandbox-home package to the hotfix version <strong>1.2.3-1</strong> in the <strong>prd</strong> environment :</p>
|
|
1521
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1522
|
+
"base": {
|
|
1523
|
+
},
|
|
1524
|
+
"composite": {
|
|
1525
|
+
"@eui/deps-base": "^18.0.0",
|
|
1526
|
+
"@csdr/core": "^7.0.0",
|
|
1527
|
+
"@csdr/integration": "^6.0.0",
|
|
1528
|
+
"@baep/sandbox-home": "^1.0.0"
|
|
1529
|
+
},
|
|
1530
|
+
"acc": {
|
|
1531
|
+
},
|
|
1532
|
+
"prd": {
|
|
1533
|
+
"@baep/sandbox-home": "1.2.3-1"
|
|
1534
|
+
}
|
|
1535
|
+
}</code></pre></div><h3>Next release cycle : next/ branch</h3>
|
|
1536
|
+
<h4>Setting up next branch to deliver a major version upgrade in the DEV environment only</h4>
|
|
1537
|
+
<p>This <strong>next/</strong> branch prefix must be used when you'll be migrating your UI package from a major version of eUI to another (most typical case), for example your package is currently in eUI 19 and you need in parallel a release of the package targeting eUI 21, create a branch from the master of this UI package called : <strong>next/eui21</strong>, then usually adapt the package.json version to a next major of the package itself for example a package version in eUI 19 is : 1.2.3, once you migrate your code to eUI 21, the version should be : 2.0.0-rc.0, this way the <strong>RC</strong> release can be delivered in parallel without impacting the previous major targeting eUI 19 in higher environments.</p>
|
|
1538
|
+
<p>Once released the package version will follow the sequence on this RC version <strong>2.0.0-rc.n</strong> where "n" is the sequence.</p>
|
|
1539
|
+
<p>Note that : an <strong>RC</strong> release can only be delivered to a <strong>DEV environment</strong></p>
|
|
1540
|
+
<p>Once ready to be pushed up the environment : so <strong>TST and up</strong>, the next/ branch is merged first to develop then master and follow the regular lifecycle of delivery.</p>
|
|
1541
|
+
<h3>Support release cycle : support/ branch</h3>
|
|
1542
|
+
<p>It's the opposite of the <strong>next/</strong>, the <strong>support/</strong> branch cycle lets you still deliver <strong>previous major</strong> version of your package in parallel with the <strong>develop and master</strong> cycle,
|
|
1543
|
+
if for example you need the next major in dev/tst/int but still continue to deliver the previous major version of the package in higher environment.</p>
|
|
1544
|
+
<p>For ease of maintenance ideally the <strong>support/</strong> branch should be called with the major version of the UI package you're targetting f.e. : <strong>support/1.x</strong> while you already have a major version of <strong>2.x</strong> of your package in lower environments.</p>
|
|
1545
|
+
<hr>
|
|
1546
|
+
<hr>
|
|
1547
|
+
<h2>Mock Server and API Integration</h2>
|
|
1548
|
+
<p>Located in portal-host repository <strong>/config</strong> folder
|
|
1549
|
+
for MyWorkplace, in its own package/repository : <strong>mywp-config</strong></p>
|
|
1550
|
+
<h3>Defining endpoints</h3>
|
|
1551
|
+
<p>The entry point to the local mock server is packages/mywp-mock/server.js.</p>
|
|
1552
|
+
<p>Add an entry for every endpoint you wish to mock:</p>
|
|
1553
|
+
<p><strong>packages/mywp-mock/server.js</strong></p>
|
|
1554
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">const euMembersController = require('./eu-members');
|
|
1555
|
+
...
|
|
1556
|
+
app.get('/api/eu-members', euMembersController.getMembers);
|
|
1557
|
+
app.get('/api/eu-members/is-member/:country, euMembersController.getMemberStatus);</code></pre></div><p>The mock server is an Express application, so endpoint definitions follow its routing syntax as described on <a href="https://expressjs.com/en/starter/basic-routing.html">https://expressjs.com/en/starter/basic-routing.html</a>.</p>
|
|
1558
|
+
<p>The euMembersController is a module we can use to contain all the functionality of the new API:</p>
|
|
1559
|
+
<p><strong>packages/mywp-mock/eu-members/index.js</strong></p>
|
|
1560
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">const euMembers = require('./eu-members');
|
|
1561
|
+
|
|
1562
|
+
exports.getMembers = euMembers.getMembers;
|
|
1563
|
+
exports.getMemberStatus = euMembers.getMemberStatus;</code></pre></div><p>Let's keep the implementation in dedicated file, and dive into examples:</p>
|
|
1564
|
+
<p><strong>packages/mywp-mock/eu-members/eu-members.js</strong></p>
|
|
1565
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">const members = ['Austria', 'Belgium', ...];
|
|
1566
|
+
|
|
1567
|
+
module.exports.getMembers = (req, res) => {
|
|
1568
|
+
res.json({ members });
|
|
1569
|
+
};
|
|
1570
|
+
|
|
1571
|
+
module.exports.getMemberStatus = (req, res) => {
|
|
1572
|
+
if (members.includes(req.params.country) {
|
|
1573
|
+
res.json({ isMember: true });
|
|
1574
|
+
} else {
|
|
1575
|
+
res.sendStatus(404);
|
|
1576
|
+
}
|
|
1577
|
+
};</code></pre></div><p>We can simulate some logic based on request using the req properties, especially req.body and req.params. In getMemberStatus() above, the value of req.params.country comes from the named route param :country as we defined in server.js:
|
|
1578
|
+
<a href="https://expressjs.com/en/guide/routing.html#route-parameters">https://expressjs.com/en/guide/routing.html#route-parameters</a></p>
|
|
1579
|
+
<p><strong>packages/mywp-mock/eu-members/eu-members.js</strong></p>
|
|
1580
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">module.exports.getMemberStatus = (req, res) => {
|
|
1581
|
+
// App called GET /api/eu-members/is-member/Greece
|
|
1582
|
+
req.params.country; // 'Greece'</code></pre></div><p>The methods of res can be chained to set different properties of the response, usually res.status() and res.json().</p>
|
|
1583
|
+
<h3>Persistency</h3>
|
|
1584
|
+
<p>The mock server can store data and persist modifications for as long as it is running. This allows you to test scenarios where API state changes over time.</p>
|
|
1585
|
+
<p>Start by defining some initial state in a db module:</p>
|
|
1586
|
+
<p><strong>packages/mywp-mock/db/eu-members/index.js</strong></p>
|
|
1587
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-js">export const generateEuMembers = () => {
|
|
1588
|
+
const members = ['Belgium', 'France', 'Germany', 'Italy', 'Luxembourg', 'Netherlands'];
|
|
1589
|
+
|
|
1590
|
+
return {'eu-members-list': members};
|
|
1591
|
+
};</code></pre></div><p>In the returned object, <code>eu-members-list</code> is the key used to access this data set. Each key must be unique across the entire mock server. A single module can define multiple data sets.</p>
|
|
1592
|
+
<p>Next, register the module in lowdb so the data becomes available at runtime:</p>
|
|
1593
|
+
<p><strong>packages/mywp-mock/db/lowdb.js</strong></p>
|
|
1594
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-js">import {generateEuMembers} from './eu-members/index.js';
|
|
1595
|
+
|
|
1596
|
+
...
|
|
1597
|
+
const euMembers = generateEuMembers();
|
|
1598
|
+
|
|
1599
|
+
const router = jsonServer.router({
|
|
1600
|
+
...euMembers,
|
|
1601
|
+
...
|
|
1602
|
+
});</code></pre></div><p>Then, create the route handlers that read from the configured data:</p>
|
|
1603
|
+
<p><strong>packages/mywp-mock/routes/eu-members/index.js</strong></p>
|
|
1604
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-js">import express from 'express';
|
|
1605
|
+
|
|
1606
|
+
import {getDb} from '../../db/lowdb.js';
|
|
1607
|
+
|
|
1608
|
+
export const router = express.Router();
|
|
1609
|
+
|
|
1610
|
+
router.get('/api/eu-members', (req, res) => {
|
|
1611
|
+
const db = getDb();
|
|
1612
|
+
|
|
1613
|
+
const members = db.get('eu-members-list')
|
|
1614
|
+
.value();
|
|
1615
|
+
|
|
1616
|
+
return res.status(200).jsonp(members);
|
|
1617
|
+
});
|
|
1618
|
+
|
|
1619
|
+
router.get('/api/eu-members/:country', (req, res) => {
|
|
1620
|
+
const db = getDb();
|
|
1621
|
+
|
|
1622
|
+
const members = db.get('eu-members-list')
|
|
1623
|
+
.value();
|
|
1624
|
+
|
|
1625
|
+
if (members.includes(req.params.country)) {
|
|
1626
|
+
return res.status(200).json({isMember: true});
|
|
1627
|
+
} else {
|
|
1628
|
+
return res.sendStatus(404);
|
|
1629
|
+
}
|
|
1630
|
+
});</code></pre></div><p>Notice the use of lowdb — this is the library used to manage mock data. Calling <code>getDb().get(key).value()</code> returns the data registered under the given key. In this case, the key is <code>eu-members-list</code>, and the returned value is the array defined in <code>packages/mywp-mock/db/eu-members/index.js</code>.</p>
|
|
1631
|
+
<p>Finally, mount the router in the server:</p>
|
|
1632
|
+
<p><strong>packages/mywp-mock/server.js</strong></p>
|
|
1633
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-js">import * as euMembers from './routes/eu-members/index.js';
|
|
1634
|
+
|
|
1635
|
+
...
|
|
1636
|
+
app.use('/', euMembers.router);</code></pre></div><p>To demonstrate data mutation, add a POST endpoint:</p>
|
|
1637
|
+
<p><strong>packages/mywp-mock/routes/eu-members/index.js</strong></p>
|
|
1638
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-js">router.post('/api/eu-members', (req, res) => {
|
|
1639
|
+
const db = getDb();
|
|
1640
|
+
const country = req.body.country;
|
|
1641
|
+
|
|
1642
|
+
db.get('eu-members-list')
|
|
1643
|
+
.push(country)
|
|
1644
|
+
.write();
|
|
1645
|
+
|
|
1646
|
+
return res.status(201).json({message: `Welcome, ${country}!`});
|
|
1647
|
+
});</code></pre></div><p>This POST endpoint adds a country to the list. The chainable methods used are:</p>
|
|
1648
|
+
<ul>
|
|
1649
|
+
<li><code>get()</code> — retrieves the data set by key</li>
|
|
1650
|
+
<li><code>value()</code> — unwraps the data for reading</li>
|
|
1651
|
+
<li><code>push()</code> — appends an element to the array</li>
|
|
1652
|
+
<li><code>write()</code> — commits the changes to lowdb, so that subsequent GET requests to <code>/api/eu-members</code> return the updated list</li>
|
|
1653
|
+
</ul>
|
|
1654
|
+
<p>Other useful methods include <code>assign()</code> and <code>set()</code> for working with object fields. See <a href="https://appliedtechnology.github.io/protips/lowdb.html">https://appliedtechnology.github.io/protips/lowdb.html</a> for more details.</p>
|
|
1655
|
+
<h3>Calling API - direct approach</h3>
|
|
1656
|
+
<p>From the application, we can now call the new endpoints, for example:</p>
|
|
1657
|
+
<p><strong>EuMembersApiService</strong></p>
|
|
1658
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">@Injectable()
|
|
1659
|
+
export class EuMembersApiService {
|
|
1660
|
+
private http = inject(HttpClient);
|
|
1661
|
+
|
|
1662
|
+
public logMembers() {
|
|
1663
|
+
this.http.get('/api/eu-members').subscribe(response => console.log(response)); // { "members": ["Austria", "Belgium", ...] }
|
|
1664
|
+
}
|
|
1665
|
+
}</code></pre></div><p>In the real-world scenario, the backend services may be present behind gateway, be versioned or customized per environment, or refactored. In other words, the URLs to endpoints will not usually match what we mocked. We can manage this by moving API definitions to configuration.</p>
|
|
1666
|
+
<h3>Variable API URLs</h3>
|
|
1667
|
+
<p><strong>Local host</strong>
|
|
1668
|
+
Add an entry to the file portal-host/EUI_VERSION/app-sources/config/modules.ts,
|
|
1669
|
+
For MyWorplace in : packages/mywp-host-ui/assets/EUI_VERSION/app-sources/config/module.ts</p>
|
|
1670
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">export const MODULES: ModulesConfig = {
|
|
1671
|
+
...,
|
|
1672
|
+
euMembers: {
|
|
1673
|
+
api: {
|
|
1674
|
+
base: 'api/eu-members',
|
|
1675
|
+
members: '',
|
|
1676
|
+
memberStatus: 'is-member',
|
|
1677
|
+
},
|
|
1678
|
+
},
|
|
1679
|
+
};</code></pre></div><p>Tips:</p>
|
|
1680
|
+
<p>The config can be nested further if it helps reflecting structure of the API. Typically, there is api.base field for the common part of URLs, and the rest is for individual endpoints.
|
|
1681
|
+
Avoid trailing slashes in the string values - it's going to be more readable if slashes are added at the time of calling the API.</p>
|
|
1682
|
+
<p>Modify the code that calls the API so it reads from the @eui/core <strong>CONFIG_TOKEN</strong>:</p>
|
|
1683
|
+
<p><strong>EuMembersApiService</strong></p>
|
|
1684
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">@Injectable()
|
|
1685
|
+
export class EuMembersApiService {
|
|
1686
|
+
private apiConfig = this.config.modules.euMembers.api;
|
|
1687
|
+
|
|
1688
|
+
constructor(
|
|
1689
|
+
private http: HttpClient,
|
|
1690
|
+
@Inject(CONFIG_TOKEN) private config: EuiAppConfig,
|
|
1691
|
+
) {}
|
|
1692
|
+
|
|
1693
|
+
public logMembers() {
|
|
1694
|
+
this.http.get(`${this.apiConfig.base}/${this.apiConfig.members}`).subscribe(response => console.log(response)); // { "members": ["Austria", "Belgium", ...] }
|
|
1695
|
+
}
|
|
1696
|
+
|
|
1697
|
+
public isMember(country: string) {
|
|
1698
|
+
return this.http.get(`${this.apiConfig.base}/${this.apiConfig.memberStatus}/${country}`);
|
|
1699
|
+
}
|
|
1700
|
+
}</code></pre></div><p><strong>Remote environments</strong></p>
|
|
1701
|
+
<p>In <strong>packages/mywp-config/assets</strong> folder, find the JSON corresponding to environment you want to connect with API.
|
|
1702
|
+
Add the configuration under "modules" field, with the same structure as started in the modules.ts file:</p>
|
|
1703
|
+
<p><strong>packages/mywp-config/assets/openid-login-config.cdn-ENV.json</strong></p>
|
|
1704
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1705
|
+
...,
|
|
1706
|
+
"modules": {
|
|
1707
|
+
...,
|
|
1708
|
+
"euMembers": {
|
|
1709
|
+
"api": {
|
|
1710
|
+
"base": "https://api.acceptance.tech.ec.europa.eu/eu-members/v1",
|
|
1711
|
+
"members": "list",
|
|
1712
|
+
"memberStatus": "is-member"
|
|
1713
|
+
}
|
|
1714
|
+
}
|
|
1715
|
+
}
|
|
1716
|
+
}</code></pre></div><p>In the above example, we point at URL to the actual backend services instead the mock server. In addition, it turned out the resource for members list would be called list instead being available from root path - having this in configuration, we don't need to change anything in code. Then, when the application is served or built for the desired environment, the values from JSON are injected to the CONFIG_TOKEN.</p>
|
|
1717
|
+
<p>(see next point for API GW configuration)</p>
|
|
1718
|
+
<h2>API Calls - API Gateway and OpenID configuration</h2>
|
|
1719
|
+
<p>My Workplace integrates EU Login through an authentication service, which will automatically handle all OpenID Connect tokens. From the UI side, it loads a self-configured client JavaScript file which will redirect to EU Login and give you back secure session cookies. Linked to it, are both the EU Login and the API Gateway tokens.
|
|
1720
|
+
When calling an API, My Workplace will proxy it to the API Gateway and will automatically pass the authentication headers to the actual API.</p>
|
|
1721
|
+
<p>The API then needs to have a servlet filter installed that handles the OpenID Connect tokens. By default, the user-based API Gateway token will be used to resolve the user's identity. This token will be reused for other API calls for several tens of minutes to reduce network overhead.</p>
|
|
1722
|
+
<p>In summary, this means that these 3 steps need to be done on your side:</p>
|
|
1723
|
+
<ol>
|
|
1724
|
+
<li>AccessTokenFilter usage within your own backend</li>
|
|
1725
|
+
</ol>
|
|
1726
|
+
<p>install the AccessTokenFilter in front of your REST services (<a href="https://citnet.tech.ec.europa.eu/CITnet/stash/projects/REUSE/repos/eulogin-token-filter/browse">https://citnet.tech.ec.europa.eu/CITnet/stash/projects/REUSE/repos/eulogin-token-filter/browse</a>)</p>
|
|
1727
|
+
<ol start="2">
|
|
1728
|
+
<li>Publish your API on the API Gateway</li>
|
|
1729
|
+
</ol>
|
|
1730
|
+
<p>publish the API on the API Gateway and allow My Workplace access to your API (<a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/pages/viewpage.action?pageId=1143508232">https://citnet.tech.ec.europa.eu/CITnet/confluence/pages/viewpage.action?pageId=1143508232</a>)</p>
|
|
1731
|
+
<p>check the FAQ here for the API GW : <a href="https://citnet.tech.ec.europa.eu/CITnet/confluence/pages/viewpage.action?pageId=1002742633">https://citnet.tech.ec.europa.eu/CITnet/confluence/pages/viewpage.action?pageId=1002742633</a></p>
|
|
1732
|
+
<ol start="3">
|
|
1733
|
+
<li>Add and register your API into MWP openId configuration files per environment</li>
|
|
1734
|
+
</ol>
|
|
1735
|
+
<p>More generic information can be found here, to give you a global idea of what those OpenID configuration files contains : (<a href="https://eui.ecdevops.eu/eui-showcase-dev-guide-15.x/docs/10-openid-connect/00-introduction">https://eui.ecdevops.eu/eui-showcase-dev-guide-15.x/docs/10-openid-connect/00-introduction</a>)</p>
|
|
1736
|
+
<p>In MyWorkplace, the default definitions are already pre-configured, on your side you just have to add your particular "module" definition :</p>
|
|
1737
|
+
<p>under the "modules" section of the file, we'll include here for example the "bulk API" into the DEV OpenID environment files :</p>
|
|
1738
|
+
<p>Note that for MyWorkplace (currently) we're distributing in on 2 seperated DEV servers (same goes for TST and INT environments) : internal at EC and external on AWS:</p>
|
|
1739
|
+
<p>First : create a feature branch from the master branch on the app-my-workplace-config repository : <a href="https://citnet.tech.ec.europa.eu/CITnet/stash/projects/CSDR/repos/app-my-workplace-config/browse">https://citnet.tech.ec.europa.eu/CITnet/stash/projects/CSDR/repos/app-my-workplace-config/browse</a></p>
|
|
1740
|
+
<p>Then within the "packages/mywp-config" folder/repository : adapt those files for registering your API for the DEV environment (same applies for other environment you can find in that list) :</p>
|
|
1741
|
+
<p>Here is an example of already defined OpenID API definitions, registrated on the API side :</p>
|
|
1742
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"modules": {
|
|
1743
|
+
...
|
|
1744
|
+
"bulk": {
|
|
1745
|
+
"api": {
|
|
1746
|
+
"base": "/gw/compass-corporate/bulk-service/dev/"
|
|
1747
|
+
}
|
|
1748
|
+
},
|
|
1749
|
+
...
|
|
1750
|
+
}</code></pre></div><p>Note that the definition structure is shown as convention, resulting in a API calls from within your UI (using the CONFIG_TOKEN) : <strong>config.modules.bulk.api.base</strong></p>
|
|
1751
|
+
<p>You're free to use any definitions you'd like within your "module" but it's recommended to respect the convention used by other teams, check the content of the OpenID files to get some inspiration</p>
|
|
1752
|
+
<ol start="4">
|
|
1753
|
+
<li>Test your API definition locally using proxy to AWS DEV server command</li>
|
|
1754
|
+
</ol>
|
|
1755
|
+
<p>Once your API has been registered, serve locally MWP Playground using the AWS DEV command, and see if the API / definition is responding correctly</p>
|
|
1756
|
+
<ol start="5">
|
|
1757
|
+
<li><ul>
|
|
1758
|
+
<li>Send a Pull Request to app-my-workplace-config repository from your branch to its master branch
|
|
1759
|
+
Send the PR to the <strong>mywp-config</strong> repository master branch, providing a valid commit message format (see : ANNEX - Conventional commit message)</li>
|
|
1760
|
+
</ul>
|
|
1761
|
+
</li>
|
|
1762
|
+
</ol>
|
|
1763
|
+
<p>The config will gets rebuilt and republish couple of minutes after this, the MyWorkplace can be rebuilt in the target environment for which the API configuration has been updated.</p>
|
|
1764
|
+
<hr>
|
|
1765
|
+
<hr>
|
|
1766
|
+
<h2>ANNEX : Package and remote migration to a next eUI version - v19 to v21 is presented here (03/2026)</h2>
|
|
1767
|
+
<p>Here are the steps to migrate a package/remote from v19 to v21, we'll take the example for MyWorkplace packages, here but it can be applied to any portal.</p>
|
|
1768
|
+
<h3>Migrate the package for v21 - build and publish it - v21 remote build for the DEV environment</h3>
|
|
1769
|
+
<ol>
|
|
1770
|
+
<li>Initialize MyWorkplace (or any portals which is supporting v21 host) locally :</li>
|
|
1771
|
+
</ol>
|
|
1772
|
+
<ul>
|
|
1773
|
+
<li><p>Clone <strong>csdr-root</strong> repository in a folder of your choice locally : important in a new folder than the previous version of MyWorkplace / portal !</p>
|
|
1774
|
+
</li>
|
|
1775
|
+
<li><p>yarn</p>
|
|
1776
|
+
</li>
|
|
1777
|
+
<li><p>Initialize the MyWorkplace host playground locally on version 21.x, this will install the necessary v21 dependencies (eUI etc...)</p>
|
|
1778
|
+
</li>
|
|
1779
|
+
</ul>
|
|
1780
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --host my-workplace-host-playground --euiVersion 21.x</code></pre></div><ol start="2">
|
|
1781
|
+
<li><p>On the package you want to migrate, create a <strong>next/eui21</strong> branch from your develop branch</p>
|
|
1782
|
+
</li>
|
|
1783
|
+
<li><p>Init the package on this newly created eUI 21 branch :</p>
|
|
1784
|
+
</li>
|
|
1785
|
+
</ol>
|
|
1786
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --pkg PKG_NAME --branch next/eui21 --skipInstall</code></pre></div><p>skipInstall here is important to prevent installation of previous versions of dependencies that we want to migrate</p>
|
|
1787
|
+
<ol start="4">
|
|
1788
|
+
<li>Run the <strong>migrate</strong> script over the initialized package :</li>
|
|
1789
|
+
</ol>
|
|
1790
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run migrate PKG_NAME -- --euiVersion 21.x</code></pre></div><p>The migration script covers most of the config setup for v21, raises the version of the package to the next major, raise the version of the dependencies that are known by CSDR (dependencies-composite.json) and adjust some known code replacement (eUI breaking changes, mywp-shared breaking changes etc...)</p>
|
|
1791
|
+
<ol start="5">
|
|
1792
|
+
<li>Iterate on your package build until it's compiling correctly locally</li>
|
|
1793
|
+
</ol>
|
|
1794
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:build PKG_NAME</code></pre></div><ol start="6">
|
|
1795
|
+
<li><p>Push the changes to the <strong>next/eui21</strong> branch, wait for a successfull completion on gitlab side, it should generate a <strong>x.0.0-rc.1</strong> version of your package, where <strong>x</strong> is the major+1 from your current version on your <strong>develop</strong> branch.</p>
|
|
1796
|
+
</li>
|
|
1797
|
+
<li><p>Request to support the creation of your v21 remote specifying that this is a migration from v19</p>
|
|
1798
|
+
</li>
|
|
1799
|
+
<li><p>A v21 remote will be created by support and a trigger repository available for you to build your v21 remote in dev : <strong>remotename-remote-eui21</strong>, you can know build your remote for MyWorkplace DEV environment.</p>
|
|
1800
|
+
</li>
|
|
1801
|
+
</ol>
|
|
1802
|
+
<h3>Activate the new v21 remote in MyWorkplace - and DEV routes activation</h3>
|
|
1803
|
+
<p>Once the new v21 remote has been published to the DEV environment, we need to instruct MWP to load it from your section route, here are the steps :</p>
|
|
1804
|
+
<ol>
|
|
1805
|
+
<li>Create a remote <strong>21.x</strong> version entry in the <strong>packages/mywp-host-ui/assets/routes/routes-base-defs.json</strong></li>
|
|
1806
|
+
</ol>
|
|
1807
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">[
|
|
1808
|
+
{
|
|
1809
|
+
"path": "home",
|
|
1810
|
+
"title": "Home",
|
|
1811
|
+
"lazyLoadDef": {
|
|
1812
|
+
"npmPkg": "@mywp/dashboard",
|
|
1813
|
+
"moduleName": "DashboardModule"
|
|
1814
|
+
},
|
|
1815
|
+
"remoteDefs": [
|
|
1816
|
+
{
|
|
1817
|
+
"euiVersion": "19.x",
|
|
1818
|
+
"moduleId": "mywp-dashboard-remote-eui19",
|
|
1819
|
+
"elementTag": "mywp-dashboard-remote-v19"
|
|
1820
|
+
},
|
|
1821
|
+
{
|
|
1822
|
+
"euiVersion": "21.x",
|
|
1823
|
+
"moduleId": "mywp-dashboard-remote-eui21",
|
|
1824
|
+
"elementTag": "mywp-dashboard-remote-v21"
|
|
1825
|
+
}
|
|
1826
|
+
]
|
|
1827
|
+
}
|
|
1828
|
+
]</code></pre></div><ol start="2">
|
|
1829
|
+
<li>Activate the 21.x remote in the MWP DEV environment in <strong>packages/mywp-host-ui/assets/routes/route-defs.dev.json</strong> file :</li>
|
|
1830
|
+
</ol>
|
|
1831
|
+
<p>from</p>
|
|
1832
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none"> {
|
|
1833
|
+
"path": "home",
|
|
1834
|
+
"remote": true,
|
|
1835
|
+
"euiVersion": "19.x"
|
|
1836
|
+
}</code></pre></div><p>to</p>
|
|
1837
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none"> {
|
|
1838
|
+
"path": "home",
|
|
1839
|
+
"remote": true,
|
|
1840
|
+
"euiVersion": "21.x"
|
|
1841
|
+
}</code></pre></div><ol start="3">
|
|
1842
|
+
<li>In the <strong>packages/mywp-host-ui/assets/routes/routes-defs-base-v21-playground.json</strong> activate your package for local development</li>
|
|
1843
|
+
</ol>
|
|
1844
|
+
<p>(note that this can be done at an earlier step to keep testing the package locally)</p>
|
|
1845
|
+
<p>create the entry :</p>
|
|
1846
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none"> {
|
|
1847
|
+
"path": "home",
|
|
1848
|
+
"lazy": true
|
|
1849
|
+
}</code></pre></div><ol start="4">
|
|
1850
|
+
<li>Add the v21 dependency version of your package in the v21 host-playground <strong>packages/mywp-host-ui/assets/21.x/app-root-playground/dependencies-composite.json</strong></li>
|
|
1851
|
+
</ol>
|
|
1852
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">{
|
|
1853
|
+
"dependencies": {
|
|
1854
|
+
...,
|
|
1855
|
+
"@mywp/dashboard": "^MAJOR+1.0.0",
|
|
1856
|
+
....
|
|
1857
|
+
}
|
|
1858
|
+
}</code></pre></div><p>where <strong>MAJOR+1</strong> is the new version of your package built earlier</p>
|
|
1859
|
+
<ol start="5">
|
|
1860
|
+
<li><p>Send PR to the <strong>mywp-host-ui</strong> repository with the changes</p>
|
|
1861
|
+
</li>
|
|
1862
|
+
<li><p>Build MyWorkplace host in DEV to apply and publish the changes</p>
|
|
1863
|
+
</li>
|
|
1864
|
+
<li><p>You can now iterate on DEV environment with your UI package in <strong>RC</strong> release from the next/eui21 branch and the remote deployed in the <strong>DEV</strong> environment (only)</p>
|
|
1865
|
+
</li>
|
|
1866
|
+
</ol>
|
|
1867
|
+
<h3>Merging next/eui21 branch to develop and master</h3>
|
|
1868
|
+
<p>Once iterations are ok, package and remote are ready to be shipped in upper environment : TST, until PROD.</p>
|
|
1869
|
+
<ol>
|
|
1870
|
+
<li><p>From the <strong>master</strong> branch create a <strong>support/MAJOR.x</strong> of your current previous version, this is for sure optional but will let you still release previous version of your package/remote in upper environment, while the next version is traveling to upper envs.</p>
|
|
1871
|
+
</li>
|
|
1872
|
+
<li><p>Merge the <strong>next/eui21</strong> branch to develop, once merged <strong>STOP the build of the pipeline</strong>, in order to adjust the version for develop/master, as the merged version of the package is still a <strong>RC</strong> version the version needs to be set to <strong>MAJOR+1.0.0</strong>, so if the version was <strong>2.0.0-rc.x</strong> in next/eui21, this version merged to develop, update it to <strong>2.0.0</strong>, commit and let the develop pipeline run to produce your first snapshot release of the 2.x version of your package.</p>
|
|
1873
|
+
</li>
|
|
1874
|
+
<li><p>Once the <strong>snapshot</strong> has been built and published, re-build the remote for DEV, now the remote should take this latest snapshot version of your package and will be published in the DEV environment.</p>
|
|
1875
|
+
</li>
|
|
1876
|
+
<li><p>Iterate on your develop branch / DEV environment</p>
|
|
1877
|
+
</li>
|
|
1878
|
+
<li><p>Merge <strong>develop</strong> to <strong>master</strong> in order to create a <strong>latest</strong> release of your package, after this being built, you can now deliver your remote in upper environments, starting with the <strong>tst</strong> one (on the remote v21 trigger, create a new pipeline => set the <strong>env_target</strong> to "tst" and launch).</p>
|
|
1879
|
+
</li>
|
|
1880
|
+
<li><p>Activate the remote route in upper environemnt in the <strong>mywp-host-ui</strong> routes config : <strong>routes-defs.tst.json</strong> and proceed the same way until PROD.</p>
|
|
1881
|
+
</li>
|
|
1882
|
+
</ol>
|
|
1883
|
+
<h3>v21 MyWorkplace package release notes and specifics</h3>
|
|
1884
|
+
<h4>csdr-core-ui</h4>
|
|
1885
|
+
<ul>
|
|
1886
|
+
<li>The language interceptor is now sending Accept-Language for any http request (no cors issue <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS">https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS</a>)</li>
|
|
1887
|
+
<li>There is a new provider available for remotes communication (in case it's really needed): <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/csdr-core-ui/-/blob/master/main/services/event-bus.ts?ref_type=heads">EventBus</a>.</li>
|
|
1888
|
+
</ul>
|
|
1889
|
+
<h4>mywp-shared-ui</h4>
|
|
1890
|
+
<ul>
|
|
1891
|
+
<li>Following the deprecation in v19, all modules are now removed (use standalone components),</li>
|
|
1892
|
+
<li>If (in v19) you were using moment based pipes / services from <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-shared-ui/-/tree/master/date?ref_type=heads">mywp-shared-ui / date</a>, make sure to flip the imports to <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-shared-ui/-/tree/next/eui21/date-moment?ref_type=heads">mywp-shared-ui / date-moment</a>; the - - Code requires minimal adaptation and it can be done in v19 already.</li>
|
|
1893
|
+
<li><a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-shared-ui/-/tree/next/eui21/date?ref_type=heads">mywp-shared-ui / date</a> now provides ng-based pipes for formatting dates (in case you don't care about DST and other more advanced features),</li>
|
|
1894
|
+
<li><a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-shared-ui/-/tree/next/eui21/numbers?ref_type=heads">mywp-shared-ui / numbers</a> and <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-shared-ui/-/tree/next/eui21/currency?ref_type=heads">currency</a> pipes have been renamed following the introduction of mywp-shared-ui / date (requires minimal code adaptations),</li>
|
|
1895
|
+
<li><a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/mywp-shared-ui/-/tree/master/common?ref_type=heads">mywp-shared-ui / common</a>: selectors of common components have not '-cp' suffix anymore.</li>
|
|
1896
|
+
</ul>
|
|
1897
|
+
<h4>cc-shared-ui</h4>
|
|
1898
|
+
<ul>
|
|
1899
|
+
<li><a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/cc-shared-ui/-/blob/master/block/services/blocks-communication.ts?ref_type=heads">BlocksCommunicationService</a> is deprecated: please use <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/csdr-core-ui/-/blob/master/main/services/event-bus.ts?ref_type=heads">EventBus</a>.</li>
|
|
1900
|
+
<li>Following the introduction of the fluid-view (TC-TD merge), the old tabs sub-entry has been renamed sidebar-menu (minimal adaptation).</li>
|
|
1901
|
+
</ul>
|
|
1902
|
+
<h3>v21 migration and code - remarks to consider</h3>
|
|
1903
|
+
<p>First of all, the code your remote depends on must be sanitised (deps of deps included):</p>
|
|
1904
|
+
<p>Move any route-definition (even for deps) in your main section package. Get rid of any code that is lazy-loading modules (lazy loading inside remotes is not supported). In this package, make sure to export all your routes-code like in <a href="https://citnet.tech.ec.europa.eu/CITnet/stash/projects/CSDR/repos/cc-task-manager-ui/browse/section/routing-module.ts">cc-task-manager-ui</a> (check the code for further details): an array of routes and a Main module that doesn't import any RoutingModule (typically called xxx_CommonModule),
|
|
1905
|
+
Since lazy-loading is not supported within the remotes, make sure xxx_CommonModule is not dependant on any forChild called,
|
|
1906
|
+
Any usage of PrimeNg components must be replaced with equivalent eui ones,
|
|
1907
|
+
Any usage of Material components must be replaced with equivalent eui ones.</p>
|
|
1908
|
+
<p>Make sure to adopt the new remotes skeleton by providing the right metadata when you migrate yours. This is particularly important for participant remotes cause it enables many new features related to inputs (WC level). Note that the new metadata should fully covered the previous needs.</p>
|
|
1909
|
+
<p>You can already find some examples at <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-config/-/blob/master/remotes/.euirc-remotes.json?ref_type=heads">euirc-remotes.json </a></p>
|
|
1910
|
+
<ul>
|
|
1911
|
+
<li>for a section example ===> cc-task-manager-remote-eui21,</li>
|
|
1912
|
+
<li>for a participant / standalone example ===> cc-task-actions-remote-eui19.</li>
|
|
1913
|
+
</ul>
|
|
1914
|
+
<p>The new flags are described at <a href="https://sdlc.webcloud.ec.europa.eu/csdr/csdr-engine/-/blob/master/resources/remotes.md?ref_type=heads">csdr-engine</a>. Note that following the evolution of angular and eUI:</p>
|
|
1915
|
+
<ul>
|
|
1916
|
+
<li>it's now optional providing a main module (if not done yet, start phasing them out),</li>
|
|
1917
|
+
<li>it's now optional using ngrx-store (try to remove it cause it's module dependent),</li>
|
|
1918
|
+
<li>there is a option to go zoneless.</li>
|
|
1919
|
+
</ul>
|
|
1920
|
+
<hr>
|
|
1921
|
+
<hr>
|
|
1922
|
+
<h2>ANNEX : CSDR commands</h2>
|
|
1923
|
+
<p>The CSDR engine is built in NodeJS, it's the same engine that is both used in your local NodeJS / Angular / eUI environment, sharing commands for building a package / building a remote / building a host etc... and the CI / gitlab environment when the pipeline is operating.</p>
|
|
1924
|
+
<p>Prior to push any changes into your <strong>UI package</strong> / local repositories, you can ensure that what you're committing will pass on CI by executing those commands locally.</p>
|
|
1925
|
+
<h3>init</h3>
|
|
1926
|
+
<p><strong>host</strong></p>
|
|
1927
|
+
<p>depending on the version of eUI the host is setup</p>
|
|
1928
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --host HOST_NAME --euiVersion 18.x
|
|
1929
|
+
npm run init -- --host HOST_NAME --euiVersion 19.x
|
|
1930
|
+
npm run init -- --host HOST_NAME --euiVersion 21.x</code></pre></div><p><strong>package</strong></p>
|
|
1931
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --pkg PKG_NAME [--skipInstall]</code></pre></div><p><strong>remote</strong></p>
|
|
1932
|
+
<p>In case you want to locally debug a remote</p>
|
|
1933
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run init -- --remote REMOTE_NAME [--skipInstall]</code></pre></div><h3>sync</h3>
|
|
1934
|
+
<p>The <strong>sync</strong> command is used to get the last of all your local dependencies coming from the portal host / the initialized UI packages / remotes locally, it also reset the package.json at the root / reset and rebuild the root tsconfig for local development usage.</p>
|
|
1935
|
+
<p>If you want to <strong>sync</strong> your local environment just execute :</p>
|
|
1936
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run sync</code></pre></div><h3>Local repositories git ops</h3>
|
|
1937
|
+
<p>2 main commands will parse local initialized repositories / folders where global git commands can be executed :</p>
|
|
1938
|
+
<p>*<strong>pull-all</strong></p>
|
|
1939
|
+
<p>for pulling all latest changes on all local repositories</p>
|
|
1940
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pull-all</code></pre></div><p><strong>checkout-all</strong></p>
|
|
1941
|
+
<p>for checkout specified branch on all local repositories</p>
|
|
1942
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run checkout-all -- --branch BRANCH_NAME</code></pre></div><h3>UI Packages commands</h3>
|
|
1943
|
+
<p><strong>build</strong></p>
|
|
1944
|
+
<p>executes eUI Angular UI package build including : audit / lint / test / build</p>
|
|
1945
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:build PKG_NAME</code></pre></div><p><strong>audit</strong></p>
|
|
1946
|
+
<p>execute only lint</p>
|
|
1947
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:audit PKG_NAME</code></pre></div><p><strong>lint</strong></p>
|
|
1948
|
+
<p>execute only lint</p>
|
|
1949
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:lint PKG_NAME</code></pre></div><p><strong>test</strong></p>
|
|
1950
|
+
<p>execute only test</p>
|
|
1951
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:test PKG_NAME</code></pre></div><p><strong>skipping options</strong></p>
|
|
1952
|
+
<p>exclude phases from running</p>
|
|
1953
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run pkg:build PKG_NAME [--skipLint] [--skipTest] [--skipCompile] [--skipAudit]</code></pre></div><h3>remote commands</h3>
|
|
1954
|
+
<p><strong>build</strong></p>
|
|
1955
|
+
<p>executes eUI Angular remote production build</p>
|
|
1956
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run remote:build REMOTE_NAME</code></pre></div><p><strong>serve</strong></p>
|
|
1957
|
+
<p>executes eUI Angular remote dev build and transfer file into target host</p>
|
|
1958
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run remote:serve REMOTE_NAME -- --host LOCAL_HOST_NAME</code></pre></div><hr>
|
|
1959
|
+
<hr>
|
|
1960
|
+
<h2>ANNEX : Conventional commit message format</h2>
|
|
1961
|
+
<p>(see : <a href="https://www.conventionalcommits.org/en/v1.0.0/">https://www.conventionalcommits.org/en/v1.0.0/</a>)</p>
|
|
1962
|
+
<p>When committing on repositories, it's important to respect the conventional commit message format, as there are pipeline checks and it will stop the build if at least a
|
|
1963
|
+
<strong>valid commit is not found from last tag</strong> of the package you want to build.</p>
|
|
1964
|
+
<p>Example of valid commit messages :</p>
|
|
1965
|
+
<ul>
|
|
1966
|
+
<li>chore(type): commit message - ISSUE_KEY OR chore: commit message - ISSUE_KEY</li>
|
|
1967
|
+
<li>fix(type): commit message - ISSUE_KEY OR fix: commit message - ISSUE_KEY</li>
|
|
1968
|
+
<li>feat(type): commit message - ISSUE_KEY OR feat: commit message - ISSUE_KEY</li>
|
|
1969
|
+
<li>refactor(type): commit message - ISSUE_KEY OR refactor: commit message - ISSUE_KEY</li>
|
|
1970
|
+
</ul>
|
|
1971
|
+
<p>in the case of a breaking change (with no influence on the version generated (see here under)):</p>
|
|
1972
|
+
<ul>
|
|
1973
|
+
<li>chore: commit message - BREAKING CHANGE - ISSUE_KEY</li>
|
|
1974
|
+
</ul>
|
|
1975
|
+
<p><strong>type</strong> represent the sub-group on where you're committing on (sub module / component of your package) and is optional</p>
|
|
1976
|
+
<p>Those commits from previous tag, will also be used to :</p>
|
|
1977
|
+
<ul>
|
|
1978
|
+
<li>automatically generate the semantic version of the package :<ul>
|
|
1979
|
+
<li>chore / fix types : patch release : 1.0.[+1]</li>
|
|
1980
|
+
<li>feat : minor release : 1.[+1].0</li>
|
|
1981
|
+
</ul>
|
|
1982
|
+
</li>
|
|
1983
|
+
</ul>
|
|
1984
|
+
<p>In CSDR engine, the <strong>BREKING CHANGE</strong> type can be used but it won't have any influence on the <strong>major</strong> version, this will be done by branching and major version manually raised by the developer once migrating f.e. to next version of eUI for your package.</p>
|
|
1985
|
+
<ul>
|
|
1986
|
+
<li>automatically generate a <strong>CHANGELOG.md</strong> entry corresponding to the commit history from last tag, this will be updated on each <strong>master/latest</strong> release of your package.</li>
|
|
1987
|
+
</ul>
|
|
1988
|
+
<hr>
|
|
1989
|
+
<hr>
|
|
1990
|
+
<h2>ANNEX : Setup AWS S3 buckets and Cloudfront</h2>
|
|
1991
|
+
<h3>Initial setup - AWS side</h3>
|
|
1992
|
+
<p>First step of the setup is the responsability of the portal team OPS, to setup the S3 buckets
|
|
1993
|
+
(it can be a single one or one per environment or one for non-prod and one for PROD environment, you'll have the freedom to choose your preferred setup).</p>
|
|
1994
|
+
<h3>Activate S3 and CDN configuration</h3>
|
|
1995
|
+
<p>Once the setup has been made, for each environment, 2 operations need to be performed, note that usually this step is performed by the BAEP core team / support,
|
|
1996
|
+
the information given here is for developers to have an overview on how this is setup.</p>
|
|
1997
|
+
<h4>Host distribution config</h4>
|
|
1998
|
+
<p>In the <strong>.config/.euirc-hosts.json</strong> where the configuration for each host is defined, the <strong>distribution</strong> entry let you define for each environment
|
|
1999
|
+
the Cloudfront URL where the website will be hosted together with the associated bucket where the distribution of the host, once built, will be transfered from the gitlab pipeline.</p>
|
|
2000
|
+
<p>Here's an example for the DSA portal CDN / S3 configuration</p>
|
|
2001
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">"distribution": {
|
|
2002
|
+
"envs": {
|
|
2003
|
+
"dev": {
|
|
2004
|
+
"baseHref": "https://dev.data-access.dsa.ec.europa.eu/",
|
|
2005
|
+
"bucket": "dsa-web-bucket-dev"
|
|
2006
|
+
},
|
|
2007
|
+
"tst": {
|
|
2008
|
+
"baseHref": "https://tst.data-access.dsa.ec.europa.eu/",
|
|
2009
|
+
"bucket": "dsa-web-bucket-tst"
|
|
2010
|
+
},
|
|
2011
|
+
"acc": {
|
|
2012
|
+
"baseHref": "https://acc.data-access.dsa.ec.europa.eu/",
|
|
2013
|
+
"bucket": "dsa-web-bucket-acc"
|
|
2014
|
+
},
|
|
2015
|
+
"prd": {
|
|
2016
|
+
"baseHref": "https://data-access.dsa.ec.europa.eu/",
|
|
2017
|
+
"bucket": "dsa-web-bucket-prd"
|
|
2018
|
+
}
|
|
2019
|
+
}
|
|
2020
|
+
},</code></pre></div><h4>Gitlab CSDR project definition of the AWS secrets key and token</h4>
|
|
2021
|
+
<p>BAEP core team once received by SECEM, will register your AWS ACCESS_KEY_ID and SECRET_ACCESS_KEY on CSDR gitlab side for those to be known by the pipeline.</p>
|
|
2022
|
+
<p>Those will be used to transfer to the associated S3 buckets when the release will be done on target environment for both the <strong>host</strong> and the <strong>remotes</strong> of your portal.</p>
|
|
2023
|
+
<hr>
|
|
2024
|
+
<hr>
|
|
2025
|
+
<p><i>This section is dedicated to support / CSDR owners only, although all the commands are available to be used locally, if you want to experiment package/remote/host creation in your local environment.</i></p>
|
|
2026
|
+
<h2>ANNEX : generate a UI package or remote for an existing host / portal (MyWorkplace / SEDIA / BAEP Portals / etc...)</h2>
|
|
2027
|
+
<p><em>NOTE: this has to be done by support or MyWorkplace / eUI team for controlling CSDR repository creation and extra manual checks</em></p>
|
|
2028
|
+
<h3>pre-requisites</h3>
|
|
2029
|
+
<p>Here are the steps for a package creation from scratch, based on eUI version skeleton provided by the CSDR engine :</p>
|
|
2030
|
+
<ul>
|
|
2031
|
+
<li>Clone of <strong>csdr-root.git</strong> and <strong>yarn</strong>, here are the steps for generating a UI package and remote from scratch :</li>
|
|
2032
|
+
</ul>
|
|
2033
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">git clone https://sdlc.webcloud.ec.europa.eu/csdr/csdr-root.git local-csdr (or any folder of your choice)</code></pre></div><p>Install the CSDR engine in the <strong>local-csdr</strong> folder (or the folder of your choice)</p>
|
|
2034
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">yarn</code></pre></div><ul>
|
|
2035
|
+
<li>Clone of <strong>csdr-config.git</strong> into a local <strong>.config</strong> folder, still in the <strong>local-csdr</strong> folder (or the folder of your choice)</li>
|
|
2036
|
+
</ul>
|
|
2037
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">git clone https://sdlc.webcloud.ec.europa.eu/csdr/csdr-config.git .config</code></pre></div><h3>UI package creation</h3>
|
|
2038
|
+
<ul>
|
|
2039
|
+
<li>Generate the UI package :</li>
|
|
2040
|
+
</ul>
|
|
2041
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --pkg PACKAGE_NAME --euiVersion EUI_VERSION [--subgroup SUBGROUP]</code></pre></div><p>where <strong>PACKAGE_NAME</strong> is in the form of : scope-name-ui</p>
|
|
2042
|
+
<p>where <strong>EUI_VERSION</strong> can be "19.x", "21.x" or "23.x"</p>
|
|
2043
|
+
<p>where <strong>subgroup</strong> is optional, by default <strong>myworkplace-ui</strong> will be used, for other supgroup (sedia-ui / sfc / etc...) the subgroup must be specified</p>
|
|
2044
|
+
<ul>
|
|
2045
|
+
<li><p>Create a feature branch in the <strong>csdr-config</strong> repo gitlab side for pushing the adapted config of the new package created</p>
|
|
2046
|
+
</li>
|
|
2047
|
+
<li><p>Push the added config of the newly created packages from the local <strong>.config</strong> folder into your own branch with a valid commit</p>
|
|
2048
|
+
</li>
|
|
2049
|
+
</ul>
|
|
2050
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">git commit -m "chore: add configuration for PACKAGE_NAME"</code></pre></div><ul>
|
|
2051
|
+
<li><p>Send a merge request from your pushed code from your branch into <strong>csdr-config</strong> master branch</p>
|
|
2052
|
+
</li>
|
|
2053
|
+
<li><p>Create the sdlc gitlab repository : for MyWorkplace under the <strong>myworkplace-ui</strong> subgroup (maintainer role required) : IMPORTANT untick the box for auto-generation of the readme.md file, the repository should be empty !</p>
|
|
2054
|
+
</li>
|
|
2055
|
+
<li><p>In the package folder created in <strong>/packages/PACKAGE_NAME</strong>, follow the gitlab instructions mainly to push on the <strong>master</strong> branch of the package</p>
|
|
2056
|
+
<ul>
|
|
2057
|
+
<li>git init</li>
|
|
2058
|
+
<li>git add .</li>
|
|
2059
|
+
<li>git commit -m "chore: initial setup - JIRA_KEY"</li>
|
|
2060
|
+
<li>git remote add origin <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/PACKAGE_NAME.git">https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/PACKAGE_NAME.git</a></li>
|
|
2061
|
+
<li>git push -u origin master</li>
|
|
2062
|
+
</ul>
|
|
2063
|
+
</li>
|
|
2064
|
+
<li><p>IMPORTANT : stop the running pipeline on <strong>master</strong></p>
|
|
2065
|
+
</li>
|
|
2066
|
+
<li><p>Create the <strong>develop</strong> branch from the master branch created on the package repository, pipeline will now be running and build a snapshot release of the package from the <strong>develop</strong> branch created.</p>
|
|
2067
|
+
</li>
|
|
2068
|
+
</ul>
|
|
2069
|
+
<h3>Remote creation</h3>
|
|
2070
|
+
<h4>Creation of a remote for a migrated eUI version of an existing UI package</h4>
|
|
2071
|
+
<p>In that case, the UI package is already existing, has been migrated to a next version of eUI, an <strong>RC</strong> release of the package has been published from a <strong>next/euiVERSION</strong> branch of the package.</p>
|
|
2072
|
+
<ul>
|
|
2073
|
+
<li>Generate the remote from an existing eUI version</li>
|
|
2074
|
+
</ul>
|
|
2075
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --remote REMOTE_NAME --euiVersion 21.x --fromEuiVersion 19.x [--subgroup myworkplace-ui]</code></pre></div><p>where <strong>REMOTE_NAME</strong> is in the form : scope-name-remote (without the version) (f.e.: mywp-dashboard-remote)</p>
|
|
2076
|
+
<p>where <strong>euiVersion</strong> is the new eUI major version of the remote (MAJOR+1),</p>
|
|
2077
|
+
<p>where <strong>fromEuiVersion</strong> is the previous eUI major version the remote is migrated from (MAJOR)</p>
|
|
2078
|
+
<p>where <strong>subgroup</strong> default is <strong>myworkplace-ui</strong>, corresponding to the gitlab subgroup repository location</p>
|
|
2079
|
+
<h4>Creation of a brand new remote (no pre-existing remote version)</h4>
|
|
2080
|
+
<ul>
|
|
2081
|
+
<li>Generate the remote from an existing eUI version</li>
|
|
2082
|
+
</ul>
|
|
2083
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --remote REMOTE_NAME [--subgroup myworkplace-ui]</code></pre></div><h4>Pushing the new remote repository and config in gitlab</h4>
|
|
2084
|
+
<ul>
|
|
2085
|
+
<li><p>Create a feature branch in the <strong>csdr-config</strong> repo gitlab side for pushing the adapted config of the new package created</p>
|
|
2086
|
+
</li>
|
|
2087
|
+
<li><p>Push the added config of the newly created packages from the local <strong>.config</strong> folder into your own branch with a valid commit</p>
|
|
2088
|
+
</li>
|
|
2089
|
+
</ul>
|
|
2090
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">git commit -m "chore: add configuration for REMOTE_NAME"</code></pre></div><ul>
|
|
2091
|
+
<li><p>Send a merge request from your pushed code from your branch into <strong>csdr-config</strong> master branch</p>
|
|
2092
|
+
</li>
|
|
2093
|
+
<li><p>Create the sdlc gitlab repository : for MyWorkplace under the <strong>myworkplace-ui</strong> subgroup (maintainer role required) : IMPORTANT untick the box for auto-generation of the readme.md file, the repository should be empty !</p>
|
|
2094
|
+
</li>
|
|
2095
|
+
<li><p>In the package folder created in <strong>/remotes-trigger/REMOTE_NAME</strong>, follow the gitlab instructions mainly to push on the <strong>master</strong> branch of the package</p>
|
|
2096
|
+
<ul>
|
|
2097
|
+
<li>git init</li>
|
|
2098
|
+
<li>git add .</li>
|
|
2099
|
+
<li>git commit -m "chore: initial setup - JIRA_KEY"</li>
|
|
2100
|
+
<li>git remote add origin <a href="https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/REMOTE_NAME_EUIVERSION.git">https://sdlc.webcloud.ec.europa.eu/csdr/myworkplace-ui/REMOTE_NAME_EUIVERSION.git</a></li>
|
|
2101
|
+
<li>git push -u origin master</li>
|
|
2102
|
+
</ul>
|
|
2103
|
+
</li>
|
|
2104
|
+
</ul>
|
|
2105
|
+
<h4>Section route activation for newly created package / remote (available only for MyWorkplace)</h4>
|
|
2106
|
+
<p>For a brand new package/remote created, a route generation script is available</p>
|
|
2107
|
+
<ul>
|
|
2108
|
+
<li>Generate the route for a UI package</li>
|
|
2109
|
+
</ul>
|
|
2110
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --route test-route --pkgName PACKAGE_NAME --euiVersion EUI_VERSION</code></pre></div><p>Once executed the route created will be available (as optional entry) in MyWorkplace global menu, routes definitions created and remote in DEV activated.</p>
|
|
2111
|
+
<ul>
|
|
2112
|
+
<li>Send a pull request to <strong>mywp-host-ui</strong> repository with the routes changes applied</li>
|
|
2113
|
+
</ul>
|
|
2114
|
+
<h4>Generate a participant UI package and remote</h4>
|
|
2115
|
+
<p>For generating a participant UI package, follow the same steps as for the section package generation (default UI package), just add this option on the generate command execution : </p>
|
|
2116
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --pkg PACKAGE_NAME --euiVersion EUI_VERSION --participant [--subgroup SUBGROUP]</code></pre></div><p>This <strong>--participant</strong> option, indicates that the package will be generated using the participant skeleton of CSDR engine.</p>
|
|
2117
|
+
<p>The following steps are the same as for the default package generation, as well as the remote creation over the UI participant package.</p>
|
|
2118
|
+
<h4>Complete section generation</h4>
|
|
2119
|
+
<p>For a brand new section in MyWorkplace, a complete section generation is available.</p>
|
|
2120
|
+
<p>It will :</p>
|
|
2121
|
+
<ul>
|
|
2122
|
+
<li>generate the UI package for the new section / route to be created</li>
|
|
2123
|
+
<li>generate the remote associated with the UI package / route</li>
|
|
2124
|
+
<li>generate the route for the section and entries in the MyWorkplace playground and DEV environment</li>
|
|
2125
|
+
</ul>
|
|
2126
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --section PKG_NAME --euiVersion EUI_VERSION</code></pre></div><p>Where PKG_NAME is the flat name of the package : f.e.</p>
|
|
2127
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --section mywp-sample --euiVersion 21.x</code></pre></div><p>The resulting package created will be : mywp-sample-ui
|
|
2128
|
+
The resulting remote created will be : mywp-sample-remote-eui21
|
|
2129
|
+
The route generated will be : "/mywp-sample"</p>
|
|
2130
|
+
<p>As the section route generation, once executed the route created will be available (as optional entry) in MyWorkplace global menu, routes definitions created and remote in DEV activated.</p>
|
|
2131
|
+
<ul>
|
|
2132
|
+
<li>Send a pull request to <strong>csdr-config</strong> repository with the configuration of the package and the remote applied,</li>
|
|
2133
|
+
<li>Send a pull request to <strong>mywp-host-ui</strong> repository with the routes changes applied</li>
|
|
2134
|
+
</ul>
|
|
2135
|
+
<h2>ANNEX : Generate a complete portal locally (complete new BAEP portal creation)</h2>
|
|
2136
|
+
<p>Locally you can generate a playground host portal with associated folders which will contain the minimal setup for every portal generated,</p>
|
|
2137
|
+
<p>For pushing the generated portal and the related repositories, contact an administrator as this is involving new projects to be created in the gitlab coporate SDLC.</p>
|
|
2138
|
+
<p>Here are the commands to be executed in order :</p>
|
|
2139
|
+
<h3>Pre-requisites</h3>
|
|
2140
|
+
<p>csdr-root cloned + yarn + csdr-config cloned in a .config folder of your local csdr-root install</p>
|
|
2141
|
+
<h3>Generate portal host</h3>
|
|
2142
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run generate -- --portal portalName --euiVersion 21.x </code></pre></div><p>Note: the portalName should be in the form : <strong>scope-name</strong></p>
|
|
2143
|
+
<p>After having generated the portal host / UI packages and remote, you can sync your project using the sync command</p>
|
|
2144
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run sync</code></pre></div><p>Then serve the portal host locally :</p>
|
|
2145
|
+
<b>Example :</b><div><pre class="line-numbers"><code class="language-none">npm run portalName-pl:start-mock</code></pre></div><p>*Note: the generation of host and remote will also generate couple of folders that will be used as triggered once pushed as repositories to gitlab respectively : <strong>hosts-trigger</strong> and <strong>remotes-trigger</strong></p>
|
|
2146
|
+
<h3>Pushing the portal in gitlab - Administrator only</h3>
|
|
2147
|
+
<p>In order to push a newly generated portal to gitlab, here are the steps to follow :</p>
|
|
2148
|
+
<ul>
|
|
2149
|
+
<li><p>in gitlab, create a new subgroup corresponding to the name of the portal, let's call it <strong>portalName</strong> here,</p>
|
|
2150
|
+
</li>
|
|
2151
|
+
<li><p>within that subgroup, create those projects, in CSDR projects, the default will be created on master</p>
|
|
2152
|
+
<ul>
|
|
2153
|
+
<li>app-portalName</li>
|
|
2154
|
+
<li>portalName-host</li>
|
|
2155
|
+
<li>portalName-home-remote-eui21</li>
|
|
2156
|
+
<li>portalName-home-ui</li>
|
|
2157
|
+
<li>portalName-shell-ui</li>
|
|
2158
|
+
</ul>
|
|
2159
|
+
</li>
|
|
2160
|
+
<li><p>Repositories push order :</p>
|
|
2161
|
+
<ul>
|
|
2162
|
+
<li>/packages/portalName-host => push (no pipeline will be running, it's a source injected repository)</li>
|
|
2163
|
+
<li>/packages/portalName-home-ui => push to master => stop the running pipeline => create a develop branch / pipeline will run and generate a snapshot release of the pkg</li>
|
|
2164
|
+
<li>/packages/portalName-shell-ui => push to master => stop the running pipeline => create a develop branch / pipeline will run and generate a snapshot release of the pkg</li>
|
|
2165
|
+
<li>/remotes-trigger/portalName-home-remote-eui19 => push to master => the pipeline will run and generate a remote snapshot for DEV delivery / will fail to deliver to S3 as not yet defined (that's normal)</li>
|
|
2166
|
+
<li>/hosts-trigger/app-portalName => push to master => the pipeline will run and generate a the host snapshot for DEV delivery / will fail to deliver to S3 as not yet defined (that's normal)</li>
|
|
2167
|
+
</ul>
|
|
2168
|
+
</li>
|
|
2169
|
+
</ul>
|
|
2170
|
+
|
|
2171
|
+
|
|
2172
|
+
|
|
2173
|
+
|
|
2174
|
+
|
|
2175
|
+
|
|
2176
|
+
|
|
2177
|
+
|
|
2178
|
+
|
|
2179
|
+
|
|
2180
|
+
|
|
2181
|
+
|
|
2182
|
+
|
|
2183
|
+
|
|
2184
|
+
|
|
2185
|
+
|
|
2186
|
+
|
|
2187
|
+
|
|
2188
|
+
|
|
2189
|
+
|
|
2190
|
+
|
|
2191
|
+
|
|
2192
|
+
|
|
2193
|
+
|
|
2194
|
+
</div><div class="search-results">
|
|
2195
|
+
<div class="has-results">
|
|
2196
|
+
<h1 class="search-results-title"><span class='search-results-count'></span> results matching "<span class='search-query'></span>"</h1>
|
|
2197
|
+
<ul class="search-results-list"></ul>
|
|
2198
|
+
</div>
|
|
2199
|
+
<div class="no-results">
|
|
2200
|
+
<h1 class="search-results-title">No results matching "<span class='search-query'></span>"</h1>
|
|
2201
|
+
</div>
|
|
2202
|
+
</div>
|
|
2203
|
+
</div>
|
|
2204
|
+
<!-- END CONTENT -->
|
|
2205
|
+
</div>
|
|
2206
|
+
</div>
|
|
2207
|
+
|
|
2208
|
+
<label class="dark-mode-switch">
|
|
2209
|
+
<input type="checkbox">
|
|
2210
|
+
<span class="slider">
|
|
2211
|
+
<svg class="slider-icon" viewBox="0 0 24 24" fill="none" height="20" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" width="20" xmlns="http://www.w3.org/2000/svg">
|
|
2212
|
+
<path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"></path>
|
|
2213
|
+
</svg>
|
|
2214
|
+
</span>
|
|
2215
|
+
</label>
|
|
2216
|
+
|
|
2217
|
+
<script>
|
|
2218
|
+
var COMPODOC_CURRENT_PAGE_DEPTH = 0;
|
|
2219
|
+
var COMPODOC_CURRENT_PAGE_CONTEXT = 'readme';
|
|
2220
|
+
var COMPODOC_CURRENT_PAGE_URL = 'index.html';
|
|
2221
|
+
var MAX_SEARCH_RESULTS = 15;
|
|
2222
|
+
</script>
|
|
2223
|
+
|
|
2224
|
+
<script>
|
|
2225
|
+
$darkModeToggleSwitchers = document.querySelectorAll('.dark-mode-switch input');
|
|
2226
|
+
checkToggle(darkModeState);
|
|
2227
|
+
if ($darkModeToggleSwitchers.length > 0) {
|
|
2228
|
+
for (var i = 0; i < $darkModeToggleSwitchers.length; i++) {
|
|
2229
|
+
$darkModeToggleSwitchers[i].addEventListener('change', function (event) {
|
|
2230
|
+
darkModeState = !darkModeState;
|
|
2231
|
+
toggleDarkMode(darkModeState);
|
|
2232
|
+
});
|
|
2233
|
+
}
|
|
2234
|
+
}
|
|
2235
|
+
</script>
|
|
2236
|
+
|
|
2237
|
+
<script src="./js/libs/custom-elements.min.js"></script>
|
|
2238
|
+
<script src="./js/libs/lit-html.js"></script>
|
|
2239
|
+
|
|
2240
|
+
<script src="./js/menu-wc.js" defer></script>
|
|
2241
|
+
<script nomodule src="./js/menu-wc_es5.js" defer></script>
|
|
2242
|
+
|
|
2243
|
+
<script src="./js/libs/bootstrap-native.js"></script>
|
|
2244
|
+
|
|
2245
|
+
<script src="./js/libs/es6-shim.min.js"></script>
|
|
2246
|
+
<script src="./js/libs/EventDispatcher.js"></script>
|
|
2247
|
+
<script src="./js/libs/promise.min.js"></script>
|
|
2248
|
+
|
|
2249
|
+
<script src="./js/compodoc.js"></script>
|
|
2250
|
+
|
|
2251
|
+
<script src="./js/tabs.js"></script>
|
|
2252
|
+
<script src="./js/menu.js"></script>
|
|
2253
|
+
<script src="./js/libs/clipboard.min.js"></script>
|
|
2254
|
+
<script src="./js/libs/prism.js"></script>
|
|
2255
|
+
<script src="./js/sourceCode.js"></script>
|
|
2256
|
+
<script src="./js/search/search.js"></script>
|
|
2257
|
+
<script src="./js/search/lunr.min.js"></script>
|
|
2258
|
+
<script src="./js/search/search-lunr.js"></script>
|
|
2259
|
+
<script src="./js/search/search_index.js"></script>
|
|
2260
|
+
<script src="./js/lazy-load-graphs.js"></script>
|
|
2261
|
+
|
|
2262
|
+
|
|
2263
|
+
</body>
|
|
2264
|
+
</html>
|