In GitHub there is a concept of "project" which allows to group issues as implementation of a cross-cutting multi-project implementation. For example, introducing a new logging framework is likely to affect multiple code projects so you can in GitHub create a new "project" which groups all issues related to this cross-cutting effort. Is there anything similar in GitLab?
Yes, GitLab provides the same-named structure - GitLab projects.
You can even import it from GitHub or other platforms into GitLab. And if that doesn't satisfy the needs completely, there's still the API.
Related
Our team uses a mono-repo, with several microservices, and some common packages between them.
I am tasked with adding CI/CD automation, and traditionally I rely in Git tags for the sem-ver and utilize comments to decide on major/minor/patch. The semantic-release node library does an good job of automating this.
The problem here is that it is a mono-repo and thus commits and tags are only useful across a global sem-ver. However in my case I have multiple microservices that each will have their own sem-ver.
One thought I have is maintaining a json manifest to store the versions of the services. By blocking direct pushes to the main branch, I can guarentee this file would not be changed on master except by the CI/CD actions.
I also would like to get some ideas from the community on what they would do in this situation? Or what they have done similar to this in the past?
I have an existing project that uses project boards on GitHub. I want to move all issues (open and closed) to projects (beta) on GitHub. Is there a way to do that automatically? Right now, I only know how to add issues manually to projects (beta).
As far as I know, there is currently no official guide on how to migrate to GitHub Projects (beta). You might want to follow this discussion on the topic: https://github.com/github/feedback/discussions/6141
However, I created a tutorial on how to migrate from the legacy project boards to the new projects (beta) myself: https://github.com/galargh/projects-migration#how-to-migrate-from-github-projects-to-github-projects-beta
It describes how to migrate cards (including column names) by either running a GitHub Actions workflow or a bash script.
Unfortunately, it does require some manual steps because projects (beta) API is not complete yet - the project itself and the Status field options have to be created manually to be precise.
After the migration, I'm also heavily using this action I created https://github.com/protocol/github-api-action-library/tree/master/add-project-items-by-content-query. I use it to periodically populate my projects based on content search queries (e.g. I automated adding all the issues that mention me - https://github.com/galargh/.github/blob/684c316/.github/workflows/add-project-items.yml).
I implemented python script that helps you migrate your project (similar to #galargh's solution) which uses the GraphQL api for the old projects too (might be more future proof) and also allows you to map column names and migrate PRs.
https://github.com/doidor/gh-projects-migration
You can now do this by enabling the Project migration feature in feature preview
Once you enable it you should see a Start migration button when you go to your Classic (not beta) Project Board
Here are the official docs on how to do it
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
We use GitHub Project to manage as it is simple and easy to integrate with git comments. I couldn't find a way to analyze the performance of the jobs? How can we get reports related to the monitoring and evaluation of the project?
The Project management inside GitHub is not catering to the evaluation of the project. You can use third-party project management applications that can be integrated with GitHub seamlessly. One example is http://hubstaff.com
We develop some custom elements using polymer. Each element lives in a separated repository under one organization. All of them has the same Travis config file so that would be logical to define and edit it in one place.
Is there any way to setup only one .travis.yml file for all repositories under specific organization?
Is there some way to specify some default Travis config for an organization?
Couldn't find any information about the topic in the Travis docs.
There is no mechanism for this (that I'm aware of) provided by the travis service itself. I've 'solved' this by scripting the update of the .travis.yml in my family of modules from a template in a higher-level repository.
This is now possible:
https://docs.travis-ci.com/user/build-config-imports
(still in beta though)