I have a GitLab project, and I want to store multiple maven projects (logically related) into that project. Would that be okay in a single GitLab Project?
A GitLab project is just a Git repository with some (very nice!) bells and whistles attached. There's no hard requirement for the entire project to produce one artifact, have a single build process, or even have a build process at all.
The recommended best practice is indeed to have a single Maven project per GitLab project in order to better utilize GitLab's CI tools, but that is not a requirement.
Related
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
For implementing multi project pipeline in gitlab, E.g the project structure is -
common-lib->deployment-lib->Microservice1
Microservice2
MicroserviceN
Incase of N no. of microservices, it would be tedious to update gitlab-ci.yaml file of common-lib.
So, the better way is to only build the services whenever the common-lib is built.
Is there a way in multi project pipeline, that I can restrict the trigger present in deployment-lib to start only if common-lib is built.
Also, any better suggestions for avoiding redundant builds of unnecessary microservices since the count is high.
Yes, pipeline subcriptions allow you to subscribe to upstream builds from downstream projects.
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.
So basically we have a project structure like below:
C:\Projects\Eclipse\Workspace->
afbEJB
rmcEJB
rmbEJB
**bridgesClient**
**sharedApp**
**framework**
**commonApp**
The ones marked in bold are standard java projects which are dependencies for the first 3 EJB projects. These standard projects are not built as JAR'rather actual projects so I am guessing in order to build EJB projects I would have to use ':Project' syntax.
Questions:
I was not able to refer to the standard projects without first creating settings.gradle file.
I had to create build.gradle file in all of the standard projects as well as the EJB projects. Why is there a mandate for creating gradle files in dependent projects as well? Cant the root project build it when it finds the project dependencies as part of the dependencies {...} ? that way there would be less number of build.gradle files in the entire workspace.
I think a better way around this would be to create JAR's for the standard projects and refer them as compile fileTree(dir: 'dir-where-jar-are-stored')?
What do you guys think?
Thanks,
Yogendra
ad 1) Yes, a settings.gradle is required for multi-project builds.
ad 2) It isn't necessary to create multiple build scripts. If you prefer, you can configure all projects from a single build script. Often, a mixture of these styles is used (configure commonalities from root script, remainder from subproject scripts).
ad 3) In general, I wouldn't turn the projects into separate builds, as this would complicate matters for build users. In particular, they'd have to execute multiple builds, and in the right order.
To learn more about multi-project builds, check out the "multi-project builds" chapter in the Gradle User Guide, and the many sample builds in the full Gradle distribution.
I'm new to both of these tools, and I'm also very new to Linux system administration, so I apologize ahead of time for what may seem like a total n00b question.
Basically, I'm starting a whole new project from scratch. Yaaay! Exciting! However, I'm a little lost on how to set up the project. I've installed both git and maven on my dev machine and run through some tutorials. I've also set up git on my server, and have successfully pushed code to it and pulled code from it.
So, first question : Is it even a good idea to use git and maven together? Git seems like the best source control system, and Maven seems like the best build system. Are they known to work well together? Or am I needlessly creating trouble for myself at this early (and precarious) stage of the project? I've used ant enough to know that I don't want to use it, and I'm not really a fan of svn, although I'll use it if I have to.
Second question : Given that these two tools work well together, what's the Best Practices way of setting them up? I know that git is "peer-to-peer", although I suppose nothing is stopping you from setting up a single repository for the git user and having all the devs sync up with that repo when it's time to do a build. Is that the right way to go? How about Maven? Maven seems kinda single-user oriented. Like, everybody sets up Maven on their own machine and has their own Maven repo, right? Or wrong? Would it make sense to create a "Maven user" on my server, and have that user do all my builds from the "main" git repo?
Apologies if I'm totally mistaken on how to use these tools. As I said, I'm pretty new to these things. Any help you have is appreciated.
(also, I'm working on Linux, doing Java dev work in Eclipse, using Spring for the framework, mysql for the data store, and Hibernate as an ORM. Don't know of any of that matters)
Thanks!
Q1: Yes, git will work well with any build systems. Usually your VCS is well abstracted with any modern build system. Ensure that you set up your .gitignore file so that you are not tracking any artifacts from builds.
Q2: The best practice is to have an integration branch to build from. While developing, use topic or feature branches. When ready, merge into the integration branch and push that up to the central repository where maven can build from. Google git-flow for more ideas. You generally want a central build server if you are working on a team to ensure you are building on the same machine. This is not the case if you are working alone or maybe just one developer.
Hope this helps.