Gitlab CI/CD integration [message #1856681] |
Thu, 22 December 2022 13:32 |
Jerome Holbein Messages: 15 Registered: June 2020 |
Junior Member |
|
|
Hi there,
We want to set up GitLab CI/CD and for now just do some smoke tests, but I haven't been able to find much help on how to do so online. I've stumbled upon these slides on how to build docker images of Scout Server and Client applications: https://wiki.eclipse.org/images/e/e9/161024_DockerAndScout_a.pdf and upon this (apparently abandoned?) Jenkins integration git repo: https://github.com/eclipse-scout/scout.ci .
Accordingly, for now I'm trying to build docker images for Server and Client, push them to our GitLab container registry and then set up a gitlab-ci.yml file to get a pipeline running, that loads, runs and links these two images into a working Scout app. While I can build the two docker images and run them locally (with a docker-compose a pointed out in the above slides), setting up an equivalent gitlab-ci.yml has been challenging. Any pointers on how to do this? Or more generally, what do you guys see as the most fitting way to provide a CI pipeline for Scout apps?
Best regards,
Jérôme Holbein
|
|
|
|
|
Re: Gitlab CI/CD integration [message #1858190 is a reply to message #1856694] |
Tue, 21 March 2023 16:01 |
Nils Israel Messages: 73 Registered: May 2010 |
Member |
|
|
Some time ago I discovered that the npm script "build:dev:watch" wasn't working as expected and that I always had to execute a "mvn package" to get the resource files of the project.ui.html project into the correct location.
That was annoying, but I didn't had any clue what was causing this.
During the update to 23.1 I had to play around with the ObjectFactory and our custom widgets and I had to restart a lot. That was so annoying that I tried to find the cause for this. I found out that the DefaultFilesystemWebResourceRootContributor is relying on a naming convention. In the standard scout setup the jetty for development is started from a module named "project.ui.html.app.dev" and the resource files are part of a module named "project.ui.html". The DefaultFilesystemWebResourceRootContributor is assuming that the name of the module with the resources is the name of the module with jetty without "app.dev" at the end. If that modules base dir does not contain a "target/dist" folder it is using the working directory as fallback.
Since we combined client and server in one application the default module name "project.ui.html" didn't made any sense and we renamed it to project.app.dev (and project.app.war). Of course, we still had the project.ui.html module with the resources which could not be found by the FileResolvers anymore.
In order to fix this, we @Replaced the DefaultFilesystemWebResourceRootContributor. The new Bean has to be placed as a "marker" in the module with the resources. To find the root folder for the resource we traverse the path of the beans class resource bottom up until we find a folder containing "target/dist". If none is found we return the workingDir like in the default implementation.
If anybody is interested, this is our implementation of the Bean.
@Replace
public class FilesystemWebResourceRootModuleMarker extends DefaultFilesystemWebResourceRootContributor {
private static final Logger LOG = LoggerFactory.getLogger(FilesystemWebResourceRootModuleMarker.class);
@Override
public List<Path> getRoots() {
var workingDir = System.getProperty("user.dir");
URI classURI;
try {
var url = this.getClass().getResource(this.getClass().getSimpleName() + ".class");
if (url==null) {
return List.of(new File(workingDir).toPath());
}
classURI = url.toURI();
} catch (NullPointerException | URISyntaxException e) {
LOG.error("Can't transform path to URI.", e);
return List.of(new File(workingDir).toPath());
}
if (classURI.toString().startsWith("jar:")) {
LOG.trace("Class is part of a jar, defaulting to workingDir. WebResourceRoot: {}", workingDir);
return List.of(new File(workingDir).toPath());
}
Path pathPart = Path.of(classURI).normalize().toAbsolutePath();
while (pathPart != null) {
Path toFind = pathPart.resolve(AbstractWebResourceResolver.OUTPUT_FOLDER_NAME);
if (Files.exists(toFind)) {
LOG.trace("WebResourceRoot: {}", toFind);
return List.of(toFind);
}
pathPart = pathPart.getParent();
}
LOG.trace("Can't find {} in path, defaulting to workingDir. WebResourceRoot: {}", AbstractWebResourceResolver.OUTPUT_FOLDER_NAME, workingDir);
return List.of(new File(workingDir).toPath());
}
}
Best
Nils
|
|
|
Powered by
FUDForum. Page generated in 0.04323 seconds