We are using mix of Jenkins & TeamCity pipelines for our Angular projects.
We want to break the build if specific version of node is not used by a project, or specific version(range of version) a library is not used. We want to have precise controls on the versions being used by developers. How to implement such build breaker in the CI/CD pipelines?
We don't have a clue if this is possible. This problem arrived after log4j issue, our teams want to have compliance on versions being used
Related
I am using ODM 8.10 and want to automate building rule app files. The code is currently configured in the old Classic Rule Project, and we are trying to avoid migrating to Decision Services at this time. I have found build jars for Decision Services but nothing so far for Classic Rule Projects. There must be a way to do this as the rule app jar files are created in the eclipse IDE when you deploy/export a ruleApp. I am trying to find out the jar files the IDE uses and the commands it calls to execute the rule app builds.
Re: "There must be a way to do this"
But you will not necessarily have access to it. The ODM product developers have experience, source code, documentation, and other tools that you do not have access to.
Having said that, there is an build/deploy API that you may be able to access via ANT. I haven't used it since switching to Decision Services when that became feasible in ODM 8.7. Standard practice before that time was to automate deployments via Ant and a "headless" version of Eclipse. If the latest online docs don't describe it, you might try the older docs.
WARNING: Classic Rule Projects are a dead end! Not only will all your effort building them in a non-standard way be wasted, I believe that it will likely be more trouble than just migrating to Decision Services (which is not usually that difficult).
In our setup we are building and deploying our UI5 app as an embedded static resource within our Spring boot maven-based application. During the CI build with the SAP Cloud SDK pipeline, the frontent tests are however not being executed.
Looking at the pipeline code, it seems to me that those stages are only executed for HTML5 modules and not for Java modules. However, the npm modules should be available as they are collected during initialization stage as far as I can see.
So the question for me is if there is a way to execute the frontend tests also in this scenario or if not, whether this intentionally not being done due to other constraints I am not aware of.
For projects using MTA/Cloud Application Programming Model this is correct. Currently, we expect only html5 modules to contain frontends and the corresponding tests. Reason for that is that MTA brings that structure by default and there were no other request for this yet. However, as it also looks like a valid setup we will discuss whether we implement that in one of the future releases. You are also invited to create pull requests.
If you are using a plain maven project generated with the SAP Cloud SDK, you can have this setup of having the frontend embedded into the webapp folder. In this case, you only need to configure the npm script ci-frontend-unit-test in your package.json in the root of the project.
This question is about the usage of jhipster-generator.
I noticed that the react support (namely generator-jhipster-react) has been merged into generator-jhipster, but I found no guide on how to generate react projects by generator-jhipster.
Could anyone identify how to create react projects with generator-jhipster?
As of today (2017-11-23) this has just been merged into the master branch, so you can use it by using the project directly from GitHub.
This should be released very soon, as it will be included in our next version 4.11.0. As this is still in development, you will need to run it with the --experimental flag. This will be documented in the release notes (this is a new flag).
I’m on a .net c# project composed by a solution with several class library projects.
The source control is managed by git using gitflow as branching model.
We have decided that we wanted to implement semantic versioning (http://semver.org/) of the project in order to follow a standard way to communicate our releases.
For that we are using GitVersionTask (via NuGet) which works pretty well with gitflow.
Every time we tag a release and we perform a build from the master branch the version of all assemblies are updated and a new release is out for delivery.
Only one of the assemblies has a public API, all the other are for internal consume. I would like to know if this is the correct way to manage the version of multiple assemblies of the same project I mean, isn’t it wrong to change the version of every assembly when only a couple (or even just one) was changed? To get thinks more complicated there is strong possibility that some of the “internal” assemblies will be used by other projects so I believe it not very wise to increment a major version of an assembly that didn’t suffer a change just because another assembly of the same project is promoting breaking changes. Should each assembly project be managed on its own repository?
Thanks in advance.
I know this is a bit of an old question, still:
I want to share a workaround that seems to be working:
GitVersion uses $(Build.SourcesDirectory) to see where the sources are located - src
We can change this using logging commands*
Workaround is to set the Build.SourcesDirectory before GitVersion task
Then gitVersion uses the GitVersion.yml from the project folder (Build.SourceDirectory) and voila - works
After that you might want to roll back the change or not - depending on your need. For me it seems it is nice to scope down to the only nuget package from the collection of nuget packages in our nugetPackages monorepo.
see GitVersion issue and comment
*Example Powershell command:
standard PowerShell task; set to inline script;
Write-Host "##vso[task.setvariable variable=Build_SourcesDirectory;]$(Build.SourcesDirectory)\$(NugetProjectName)"
There is certainly nothing in GitVersion that would help with having separate projects within the same repository. The guidance that we would offer here is that you should use different repositories for the different parts of your application. That way they can be versioned/updated at their own cadence.
I've got a VS2013 solution with a mix of NodeJS (using TypeScript) and C# class library projects (they're bound together by EdgeJS). Where the NodeJS projects are concerned, one can be considered a library (for a RabbitMQ bus implementation), two are applications which are meant to be hosted as part of a fourth project with both using the bus.
So, one project (host) which will depend on three projects (bus, app1 and app2) (it starts the bus, and passes it to app1 and app2).
Of course, I could just lump all these projects together and be done with it - but that's a horrible idea.
How do I package these projects up for proper reuse and referencing (like assemblies in traditional .NET)?
Is that best done with NPM? If so, does VS provide anything in this area? If not, then what?
Note that, aside from the Bus project, I'm not looking to release these publicly - I'm not sure if that changes anything.
In general, if something can be bundled together as an independent library, then it's best to consider this a Node package and thus, refactor that logic out to it's own project. It sounds like you've already done this to some extent, separating out your bus, app1, and app2 projects. I would recommend they each have their own Git repositories if they are separate packages.
Here's some documentation to get you started with Node packages:
https://www.npmjs.org/doc/misc/npm-developers.html
The host project, if it's not something you would package but instead deploy, probably does not need to be bundled as a Node package. I would instead just consider this something that would be pulled down from Git and started on some server machine.
With all that said, your last line is important:
I'm not looking to release these publicly
GitHub does have private repositories, but as of now npmjs.org does not have private repositories. There are options to create your own private repository (Sinopia and Kappa offer different ways of accomplishing this), but if you don't want this code available for everyone do not deploy it do npmjs.org. You can still package it up in the way I've outlined it above, just not deploy it as of yet.