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)
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 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 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.
Anybody know if it is possible to pass in a repo name / base the build on a dynamic repo name? This would allow us to share the same build definition across different branches, cutting down on definitions when creating a feature branch, etc.
When using a TFVC repo we would store the different releases in the same repo but different paths. We could reuse the same build definition across different releases/FB's by altering the source path such as $/product/$(release)/......
It appears Git likes to have the repo hard-coded into the build (hence the dropdown - no way to plug in a variable.
While the question is targeted to On-prem Azure DevOps, if it is possible in the hosted environment it would be helpful to know.
I recommend using YAML build templates. By default these check out "self" and are stored in the repo. That way they work on forks, branches etc. Each branch can contain tweaks to the build process as well.
With the 'old' UI based builds this isn't possible.
What you are looking for is actually two things:
templates - this allows you reuse definition accross different pipelines
triggers - this allows you to trigger pipeline when commit happens on different branches
Looks like Task Groups solved the need (mostly). I was hoping to have one build definition that could be shared across multiple branches; while this appears to be possible on the hosted model, on prem is different.
I am able to clone a build (or use templates) to have an entry point into the repo/branch to get the sources, then pass off the work to a common task group. If I need to modify the build process for multiple branches, just modify the task group.
seeking for advice about such problem.
We have stack of microservices written on NodeJs and running on Kubernetes cluster. We have separate GitHub repository for each of them and currently using Circleci for our CI/CD process. As of now we have about 25-30 repos, but their number will increase and problem that we faced now is that we need to have Circleci config yaml in each repository and if we need to change something globally in our ci/cd pipeline, we need to update this in each repository, which is obviously pretty painful process and Circleci doesn't support to have one config file for multiple repos.
I believe our situation/setup in terms of multiple repos is not unique, does anybody have experience/ideas of which CI tool support described scenario of having one config file for multiple repos?
Below are 2 approaches that I considered when had to deal with similar situation. You'd need to define for yourself what you want to optimize for and make a decision based on that
Optimizing for flexibility and isolation. In this scenario instead of making all repos use the same config file, you're keeping the file in each repo and automating how you manage this file.
For example: you'll have to create a CLI tool or a script to automate copying circle file and committing to appropriate repos (whenever a change needs to happen)
PROS: isolation - all repos have their own configuration, if you ever going to have a golang microservice or different config in one of your nodejs services, modifying CI pipeline wouldn't be an issue
CONS: a bit of extra work to write automation around managing this config separately
Optimizing for easier maintainability. Figure how to share single pipeline configuration across your repos.
For example: use git submodules for keeping circle.yml file, or use separate npm package with circle.yml file. Another alternative is to use a CI tool that supports templating, then define pipeline template and re-use it for each individual pipeline (one of the CI tools that supports it - Teamcity)
I personally picked approach #1 in similar situation. IMHO, this is a price one have to pay when one decides to go with microservices to not end up with a platform that is rather a distributed monolith :) also I really liked when all repos are descriptive and self contained and CI pipeline as code is one of the ways to help achieve that
In my mind you have 2 options - you could have a single CI job/config that can deploy any single/multiple services (if all the services are the same). Or if every service is different than you need a separate job/config for each. If it's somewhere in the middle it's a question of whether you want a single job that has a bunch of if/then statements e.g. "if repo = user then do this special thing." The if/then approach worked fine for me up to a point, but eventually, there were too many special cases at it was easier to just go with the unique config for each service.
I solved the issue of it "being hard to make a 1 line change across 30 git repos" by having a git superuser. Basically, normal users can only merge using PRs, but the superuser can commit directly. Since I'm only changing things like config files there are rarely merge conflicts or broken test cases so it works. Here's some sample code:
#!/usr/bin/env bash
for dir in /temp/*/
do
cd $dir
git pull
sed 's/Nick/John/g' report.txt > report_new.txt
git commit -m "CI change" && git push
cd ..
done