Is there a way to maintain two different update sites/p2 repositories pointing to same folder having the plugins and features files?
I need to to maintain two sites: one for full fledged features list and one with limited features. So instead of maintaining duplicate copies of features and plugins, I want to refer it to full fledged site directory's features and plugins. How can I achieve this?
The p2 artifact repository format allows to configure the location where it expects the artifacts through mapping rules. On of the default rules is
<rule filter='(& (classifier=osgi.bundle))' output='${repoUrl}/plugins/${id}_${version}.jar'/>
So if for example your full repository is at http://example.org/full/ and the limited repository at http://example.org/limited/, you could have the limited repository point to the artifact files in the full repository with the following rule:
<rule filter='(& (classifier=osgi.bundle))' output='${repoUrl}/../full/plugins/${id}_${version}.jar'/>
Just update all the rules in the same way, and it should work. Never tried this myself though.
Related
I am starting up a development team within my organization and we are managing all of our initiatives under a single Azure DevOps Project. To be clear I am trying to avoid using the word "projects" here to prevent confusion with the ADO Project terminology, so I am using "initiatives" in this post...
Over time we expect to maintain a large quantity of initiatives (likely hundreds over time) as we cater to many groups across our company. Some of our initiatives will be highly related to each other but should be managed independently for commit histories. For related initiatives we would prefer to manage them under a single Repo but separated into different folders. For example, we may have a dll that will be heavily utilized by many related plug-in like applications. The dll and plug-in applications would preferably be maintained within the same Repo as sub-repos if possible.
Additionally, there will be many categories of related initiatives which would be hosted in other Repo(s).
My question is what is considered best practice to maintain a large number of initiatives, some related and some unrelated, in Azure Repos? I read some things about Git Submodules but am struggling to figure out how to make/manage distinguished submodules in Azure Repos. Is this the best approach, or is it even possible in ADO? Alternatively is it better practice to utilize independent repos for each initiative, and try to group them via a predetermined naming convention and just call upon multiple repositories in the Pipeline?
Thanks in advance! I am relatively new to ADO.
I agree with mason that submodules can be complicated, it is worth effort
Let us say you are developing web app
You have repository "AwesomeApp" that houses code that needs to compile into production code
You could create repo of utilities "UtilitiesRepo"
This repo will never be public and exist just for your convenience
Under the "UtilitiesRepo", you will have some structure similar to following:
scripts/
development_build/AwesomeApp/
.gitmodules
azure_pipelines.yml
Directory "development_build" will become top level copy of "AwesomeApp" using submodules
At top level of "UtilitiesRepo", .gitmodules will have all information to pull down copy of "AwesomeApp" for build/test purposes
[submodule "AwesomeApp"]
path = "development_build/AwesomeApp"
url = https://dev.azure.com/AwesomeApp
branch = CurrentDevBranch
Populate development_build/AwesomeApp with command:
git submodule update --init
Submodule path 'development_build/AwesomeApp': checked out 'CurrentDevBranch'
Now copy of all files will be in development_build/AwesomeApp/
If "AwesomeApp" needs library, you can add that as submodule since directory development_build is just placeholder for copies of other repos
Just add it as submodule and your "scripts" can access and build/test both:
development_build/AppLibrary/
development_build/AwesomeApp/
In a project I'm planning to have following items/projects:
.Net Server, Ionic App, Angular Website and a C# Admin tool.
At first I made a project, created one repository and folders; Server, App, Website and AdminTool in the root. But as I want to use pipelines and structure my code best possible way, I'm thinking it might have some advantages creating a repository for each project, in my project.
This way I will trigger exactly the pipeline of the project which needs to be build and it might be more module structured.
But I also see the disadvantage of having to push multiple times for the same feature - Each for each involved project (e.g. IonicApp and Server). This way it's not that clear what is made across projects for one feature, which could be seen in one push.
Which way to structure this would you recommend?
Generally, a Git repository on Azure Repos should be no larger than 10GB. This aims to ensure reliability and availability for all customers.
If you put too many projects into one repository, and these projects may also contain some large files, it may dramatically increase the time to checkout, branch, fetch, and clone your code. This could bring you a bad experience with Git. For more details, you can see "Git limits".
So, in your case, maybe you can consider using Submodules.
Create a repository for the main project.
Create a repository for each sub-project.
Set the repositories of sub-projects as the submodules of the main project's repository.
For the source codes of the features that are involved in multiple projects, you also can set up a specific repository for each feature, and then set the feature repositories as submodules of the involved project repositories.
With this way, you can set up the pipeline for each repository. And you also can using the "pipeline-completion triggers" feature when you want the changes in the submodule repositories also can trigger the pipelines for the repositories that is using the submodules.
A separate repository for each project is highly recommended and considered best practice.
With this you will have benefits, like;
smaller sized repos,
every project integration with CICD separately.
Because at the moment you will be updating single app project, so why to bother other running projects
I'm actually thinking about the pro and cons about using NuGet. In our current software we're storing each external reference in a common reference folder (which is commited to our SW versioning system). Over time this approach becomes more and more painful because we've to store different versions to the same library.
Since our devs are sometimes at the customer site (where not all customers are offering internet connectivity ...) we won't use NuGet directly, because NuGet packages can't be restored.
Based on that I'm actually thinking about using NuGet and store the packages folder in our SW versioning system.
Does anybody know if there are some disadvantages about this solution? Does anybody have a better proposal?
Thx.
I would argue against storing external nuget packages in your version control system.
It's not your application's responsibility to archive third party packages. Should you need to take care of that risk then build a solution intended for such (for example: use private nuget repository that's properly backed up).
Avoid duplication in code base - provided you use properly released packages, then the packages.config file content is sufficient for reliably reproducing the exact dependencies your application needs.
Synchronization is an effort - keeping packages.config and packages folder in sync- once you start including them in source control every developer working with packages would monitor and add or remove packages to source control.
If devs ever forget to add then local build still fails.
If they forget to remove no longer necessary piece then your downloadable set would contain junk.
VCS dataset size - storing them would needlessly enlarge your version control storage. Quite often the packages contain N different platform dlls, tools and whatnot which add up quite fast. Should you keep your dependencies constantly up to date, then after 10 years your VCS history would contain huige amount of irrelevant junk. Storage is cheap, but still..
Instead, consider having a private nuget repository with the purpose of serving and archiving the packages your application needs and set up your project to check your project nuget repository first. If your developers need offline compile support then they can set up project repository mirrors on their build boxes and configure the following fallback structure for repos:
Developer local project repository (ex: folder)
Shared project repository (ex: Nuget.Server)
(nuget.org)
A guide how to configure multiple repositories can be found here: How to configure local Nuget Repository.
In my project, I want to take an existing Yocto setup for the Automotive Grade Linux distribution and add some layers with recipes for our own components.
There exists a manifest file, publicly available, on their gerrit site. What I'd like to do is basically
<manifest>
<include url="<url of AGL manifest>" />
<remote name="mysite" fetch="ssh://gerrit.mysite.com" />
<project name="mylayer1" path="mylayer1" />
<project name="mylayer2" path="mylayer2" />
</manifest>
The aim being that a repo init command pointed to my manifest first fetches all the repositories mentioned in the "included" manifest, then proceeds to fetch all my own meta layers.
The problem is that the include element is meant for including other manifests within the same repository specified on the repo init command line.
I could simply copy their manifest into my own repository, with a different name, and create my own manifest along side it. Or I could just reproduce their file and edit it.
But maintaining it will be a pain and extremely error prone. Especially as the upstream manifest is used not only to specify the repositories, but to pin each one to specific commits as a form of version control within Yocto.
I can't believe such an obvious use-case hasn't been considered and addressed.
So, at the risk of being closed as "too broad" or for requesting recommendations, has anyone already solved this problem? If so, how?
I highly doubt there is a way to do this using the repo tool.
Wind River has a solution, and there has been talk of moving this into oecore:
https://github.com/Wind-River/wr-lx-setup
I'm not sure if this will do exactly what you are looking for, but it solves the problem that you are describing.
Historically, people have used repo (freescale-community-bsp), combo-layers (Ostro), or simply rolled their own solution. This setup tool is an attempt to standardize the way layers are assembled.
You can use local_manifest.xml. Under .repo/ create a directory named local_manifests/. You can add a file local_manifest.xml
You can add you own remote, default and projects that are to be fetched from that remote.
I have used this feature with repo 1.23
We used nuget.server 2.8 to create a private feed for hosting nuget packages (mostly chocolatey packages) in our organization. I would like to improve/expand the indexing capability but I can't figure out how to do that.
I know in a typical nuget server feed, all the .NUPKG files would be in the root of the package path specified in the config. Long story short, we have a requirement for a folder structure in that package feed as different groups within the organization will be using SVN to commit data which ends up here. To easily manage this, we need a more complex folder structure.
However what I have found is that .NUPKGs in the root of the package path or one folder deep are indexed and available via the feed. Once you go two folders deep, the NUPKG files aren't indexed and aren't available via the nuget feed. Is there a relatively easy way I can change that? Is that a setting specified somewhere? I can't seem to find where this limitation is coming from. Any direction would be outstanding.
We've had a few users request such a feature for ProGet, but ultimately decided against implementing the feature because of the problem of not only dealing with duplicate packages, but communicating that problem to the user.
Remember that a valid NuGet package must have a file name that matches its version+id (e.g. MyPackage.1.2.nupkg can only be MyPackage v1.2). Thus if you have folderA\MyPackage.1.2.nupkg and folderB\MyPackage.1.2.nupkg, which is the valid? Do you invalidate both? Etc.
That said, it's trivial to implement, so you could simply use the ProGet SDK to build your own package store that inherits from the default, but iterates subdirectories as well.
As a side note, if you're serious about maintaining a private repository, you really should get something other than NuGet.Server. There are several available that can manage chocolately packages.
Symlinks is your best bet. You will just want to symlink those files up on a regular basis with a scheduled task.
I have to second Karl's answer on using something better than NuGet.Server. Depending on your growth potential, it can start to become unusable fast after you have 100+ packages in the repository. Note: I haven't checked this myself since 2012, it's possible it has better support now for multiple packages.