CODEOWNERS: Exclude group from directory (git) - github

My team <team-1> is sharing a github repo with <team-2>. The repo looks something like this (Simplified example):
infrastructure/
|
|-- .github/CODEOWNERS
|
|-- directory1/
|
|-- subdirectory1.1/
|
|-- subdirectory1.2/
|
|-- directory2/
|
|-- subdirectory2.1/
|
|-- subdirectory2.2/
|
|-- directory3/
|
|-- subdirectory3.1/
|
|-- subdirectory3.2/
<team-2> is the CODEOWNER of every directory in the repo, and my team <team-1> owns only subdirectory1.1 and subdirectory2.1.
In otherwords the CODEOWNERS file looks something like this:
github/CODEOWNERS
* #mycompany/team2
/infrastructure/directory1/subdirectory1.1 #mycompany/team1
/infrastructure/directory2/subdirectory2.1 #mycompany/team1
Given the aforementioned, what I would like to do is exclude team2 from every folder that team1 owns, ideally without removing the wildcard in the codeowners file.
* #mycompany/team2
/infrastructure/directory1/subdirectory1.1 #mycompany/team1 AND EXCLUDE TEAM2
/infrastructure/directory2/subdirectory2.1 #mycompany/team1 AND EXCLUDE TEAM2
What is the best way to do that without rewriting the whole codeowners logic?

According to the documentation, your example should work just fine.
Quote from the example:
# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only #js-owner and not the global
# owner(s) will be requested for a review.
*.js #js-owner
So, in this case, it seems that one of the following is the case:
Github has fixed the issue, their docs are up to date, and your example now works just as you'd like it to.
OR: Their docs are incorrect and Github needs to fix either the feature or their docs to accurately describe behavior.

GitHub native option: GitHub Action
You can try and configure the GitHub Action mszostok/codeowners-validator which can validate the GitHub CODEOWNERS file based on specified checks.
For instance:
notowned: Reports if a given repository contain files that do not have specified owners in CODEOWNERS file.
Non-GitHUb native options
Gitolite
If by "code owner" you means push/write access to a folder, this is not supported natively by Git, or GitHub: if you can push to part of a repository, you can push to all of the repository.
What you might consider is pushing to an intermediate gateway repository, on a server you control, and where you can set-up an authorization layer, like gitolite
With Gitolite, you can with VREF restrict pushes by the names of dirs and files changed.
In your case:
repo foo
RW+ = #team2
R = #team1
RW VREF/NAME/infrastructure/directory1/subdirectory1.1 #team1
RW VREF/NAME/infrastructure/directory1/subdirectory2.1 #team1
Once the push is validated by Gitolite, that same server could in turn push to GitHub.
Split repository and git filter-repo
But a more natural way would be to split the repository in two, referencing the team1 content in the main parent teeam2 repository, as a submodule.
Not easy though, considering it would involve history rewriting, and folder reorganization.

In theory, prefixing a line with ! should work, since
the syntax for CODEOWNERS should be the same as for .gitignore (see https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax)
.gitignore allows excluding (i.e. re-including) patterns by prefixing ! (see https://git-scm.com/docs/gitignore#_pattern_format)
In practice, though, I tried this and the CODEOWNERS lines starting with ! are invalid according to mszostok/codeowners-validator checks, so, no luck.

Related

How to get source branch from google cloud build trigger on push when merging

I am merging 'feature-branch' onto 'dev-branch' from a github pull request. I am using a google cloud build trigger that is triggered on push to 'dev-branch'. From what I can tell in the documentation of substitution variables, there are no substitution variables to get the name of the branch that I am merging from - 'feature-branch' and only the branch that I merging to - 'dev-branch'. Is there a way or a workaround to get information (name, sha, id, etc.) of the branch that is being merged from on a google cloud build trigger from a push to branch event?
Presumably you can have some naming conventions on the first line of the commit message (happens at merge pull request "event"), so that this line includes the source (or head) branch name (the source of the merge - in your words - 'feature-branch').
Then, you can create a substitution variable:
substitutions:
_COMMIT_MESSAGE: $(commit.commit.message)
here is a documentation link: Creating substitutions using payload bindings
And use that variable in some build step to get the the head branch name:
mapfile -t commit_lines <<< "${_COMMIT_MESSAGE}"
source_branch="$(echo ${commit_lines[0]} | <<add your command here following naming convention for the commit message>> )"
echo "=> My source branch name: ${source_branch}"
After that you can use the source branch name.

How to inlude multiple doxyfiles in a master doxyfile?

I am working on a project which has multiple modules with their own doxyfiles. My idea is to have a single master doxyfile which can include other private doxyfiles to create a one big documentation of the project. The directory structure looks like following:
MyProject+
|-Private_Prj1+
| |-Doc+
| |-doxyfile_privateprj1
|-Private_Prj2+
|-Doc+
|-doxyfile_privateprj2
|-Doc+
|-doxyfile_myproject(AKA Master Doxyfile)
How can I configure the doxyfile_myproject to include doxyfile_privateprj1 and doxyfile_privateprj2 in such a way that when I run Doxygen on the doxyfile_myproject, it then sequentially runs other doxyfiles?

Taking github repo public causes problems with Dist::Zilla

I have a module, built with Dist::Zilla. I have Dist::Zilla set up to automatically push changes out to my GitHub repo. Works great when the repo is private.
However, as soon as I make the repo public, I start getting errors during the build process. Specifically, these lines in the dist.ini
[Bugtracker]
web = http://github.com/myaccount/%s/issues
If I comment out these lines, it works. With these lines left in, I get an error:
Duplication of element resources.bugtracker.web at /Users/me/perl5/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.4/Dist/Zilla.pm line 595.
OK, so fine, I comment out the lines. However, another problem crops up. The version number of my builds no longer autoincrements and is stuck at the same number every time I try to release a build.
Is there some configuration setting I need to change with Dist::Zilla so it will play nice with public github repos? Here is the full dist.ini file:
name = Module-Test
author = me
license = Perl_5
copyright_holder = Me
copyright_year = 2018
[Repository]
;[Bugtracker]
;web = http://github.com/sdondley/%s/issues
[Git::NextVersion]
[GitHub::Meta]
[PodVersion]
[PkgVersion]
[NextRelease]
[Run::AfterRelease]
run = mv Changes tmp && cp %n-%v/Changes Changes
[InstallGuide]
[PodWeaver]
[ReadmeAnyFromPod]
type = markdown
location = root
phase = release
[Git::Check]
[Git::Commit]
allow_dirty = README.mkdn
allow_dirty = Changes
allow_dirty = INSTALL
[Git::Tag]
[Git::Push]
[Run::AfterRelease / MyAppAfter]
run = mv tmp/Changes Changes
[GatherDir]
[AutoPrereqs]
[PruneCruft]
[PruneFiles]
filename = weaver.ini
filename = README.mkdn
filename = dist.ini
filename = .gitignore
[ManifestSkip]
[MetaYAML]
[License]
[Readme]
[ExtraTests]
[ExecDir]
[ShareDir]
[MakeMaker]
[Manifest]
[TestRelease]
[FakeRelease]
Your [Bugtracker] entry leads to duplication because you are also setting the bugtracker through [GitHub::Meta]. Choose one or the other.
As for version number management, note that [Git::NextVersion] is based on your git tags. Make sure that these tags are present in your local repository and have the correct format. That plugin uses a command line invocation similar to this to obtain all tags:
git rev-list --simplify-by-decoration --pretty=%d HEAD | grep -oE 'tag: [^,)\s]+'
Public GitHub repos should not be a problem for Dist::Zilla – this is exactly the setup most dzil distros use anyway. But interactions between multiple plugins can lead to hard to track down bugs, especially since the order of plugins is important. It can help to organize your plugins by the phase in which they run, and to test whether the problem persists after removing optional plugins. It also tends to be better to start with a simple dist.ini and add plugins as pain points in your development process become apparent.

Configuring VCS of Teamcity for code checkout

I am trying to specify rather complicated labeling rule in VCS of Teamcity. Not sure if what I am trying to do is possible or not.
This is my directory structure I have inherited.
mysvn/abc/repos
|
-TestDomain
-TestSystem
|
-MyFrameWork
-MySoftware
|
-MySoftwareDevices
-MySoftwareFiles
|
-branches
-tags
-trunk1
-MySoftwareDriver
|
- branches
- tags
- trunk2
I want to specify such a rule that in the working directory of the checkout directory of Teamcity has structure like this:
Teamcity checkout directory
|
-FolderA
-FolderB
Where FolderA has contents of trunk1 and FolderB has contents of trunk2.
Is it possible to be done?
SVN URL like:
mysvn/abc/repos/TestSystem/MySoftware/MySoftwareFiles/trunk1
does give me trunk1. But I need contents of trunk1 and trunk2 under two different folders in the same build checkout directory.
Labeling I have been using: trunk=>tags
Ok got the thing working. Its kind of hit and trial. Hoping someone comes up with proper explanations.
Labeling rules still has:
trunk=>tags
The SVN URL : mysvn/abc/repos/TestSystem
It is the checkout rules which I added:
-:.
+:MySoftware/MySoftwareFiles/trunk1=>MyDir/FolderA
+:MySoftware/MySoftwareDriver/trunk2=>MyDir/FolderB

GitHub Api: How to get Root :tree_sha of a repository?

How do I get the Root :tree_sha of a GitHub repository via the GitHub API?
The GitHib API help pages don't seem to explain this critical piece of information:
http://develop.github.com/p/object.html
Can get the contents of a tree by tree
SHA
tree/show/:user/:repo/:tree_sha
To get a listing of the root tree for
the facebox project from our commit
listing, we can call this:
$ curl
http://github.com/api/v2/yaml/tree/show/defunkt/facebox/a47803c9ba26213ff194f042ab686a7749b17476
Each commit contains the sha of the entire tree as of that commit.
Use the API to get a JSON object representing the master branch.
https://api.github.com/repos/:owner/:repo/branches/master
That branch's last commit includes the tree's sha that I think you're asking for.
This bit of code demonstrates how to get the head_tree_sha in Python.
import requests
token = '0...f'
key = {'Authorization':'token '+token}
master = requests.get('https://api.github.com/repos/'+owner+'/' + repo '/branches/master', headers=key)
master = master.json()
head_tree_sha = master['commit']['commit']['tree']['sha']
https://developer.github.com/v3/git/commits/
http://develop.github.com/p/commits.html
The commit tells you its tree sha.
[EDIT]
If you want the tree sha of a subfolder cd into the parent folder of the one you're interested in and run:
git ls-tree HEAD
If you want Root tree sha:
git show HEAD --format=raw
1st line has commit sha
2nd line has tree sha
I'm not sure about the GitHub API — however if you want just the hash you can use this command in your clone:
git show HEAD --format=%T | head -1
Or use %t for the abbreviated hash.