I have allowed a certain usergroup to create branches under a namespace; refs/heads/patch/*.
When a new branch has been created here, the same users should have permission to push an annotated tag that resides on that branch, but not elsewhere.
How can this be accomplished?
My initial (bad) idea was to give this group the "push annotatad tag" permission for /refs/tags/patch/*. But of course this only creates the restriction that tags must be named "patch/tag_name" and does not solve my problem.
This isn't possible out of the box, but I think you can write a ref-update hook to enforce such a policy. I'm assuming the hook is called for all ref updates, including tags, but I'm not completely sure of that.
Before starting, make sure you've figured out the semantics for how to evaluate a tag. Since neither tags nor commits belong to or reside on a branch you'll have to use a more elaborate condition. Perhaps: "For this group of users, allow the tag if the commit it points to is reachable from one or more refs matching refs/heads/patch/* but only if it's also not reachable from any other refs"? I think that's a good starting point, but it will block tags that point to commits "on" patch branches if the patch branch has been merged to, say, master. This may or may not be acceptable in your case.
Related
I'm having trouble understanding how the newer Branch API Basic Branch Build Strategies interact with each other.
What I'd really like is to understand how to understand and craft rules - but for now I'm happy to solve a concrete example:
What I'd like to get is:
Build all branches selected by the SCM rules (Regular Branches), but skip initial builds on branch discovery
Build all pull requests (change requests) selected by the SCM rules
Allow commit messages with a "skip pattern" to skip building a particular change (in a pull request or on a branch)
The building blocks from the Basic Branch Build Strategies seem like a good match at first blush - we have:
Change requests
Regular Branches (or I could use named branches by regexp/wildcard)
"Skip build trigger if commit message contains" to skip by regexp from messages
"Skip Initial build on first branch indexing"
However when all of these are added neither of the skip rules seem to take effect. This could make some sense if the combined strategies are "logically or'ed". Every build candidate is a branch and/or a pull-request so they already match
So an alternative is to combine using the "All strategies match" and "Any strategies match".
All Strategies Match
Any Strategies Match
Regular branches
Change requests
Skip build on message
Skip build on first commit
Now my pull-requests don't build automatically.
I suspect with enough levels of "Any" and "All" I might be able to get something right, but it seems complicated.
Additionally the "Skip" strategies are unclear on how they interact with the "All" filter - since they are negative.
Even more confusingly the individual strategies can be re-ordered - although by default they seem to have a preferred order. I can't see how that interacts through "All", "Any" or just the top-level list.
Can anyone clarify how these strategies interact? I have found no relevant documentation.
We have 6 people on the project team: 1 Tech-lead and 1 Assistant Tech-lead.
In our branch policy we want to require that only the Tech-lead or Assistant Tech-lead can approve the pull request. We only need approval from one of them to avoid a bottleneck if the other one is on leave.
The problem is there are only 2 choices in the branch policy settings:
Specifying the number of required approvers (which will not work since normal developers would be able to approve as well)
Specifying the actual person to approve (which will not work since both of them will be required and cause a bottleneck when one is on leave)
Can someone please point us in the right direction?
You can provide required reviewers that are automatically added to each PR. These reviewers can also be groups.
Do this:
Create a group that contains your tech lead and assistant tech lead and.
Make that group a required approver under Automatically include code reviewers
You should get something like this:
Your statement normal developers would be able to approve as well is only true if the group that is required contains your normal developers.
This way at least 1 person from provided group (in this case Developers) must approve a PR. If you want you can also provide a path filter to require only reviews on certain changes or assign a different group for files or folders.
for those who are on Bitbucket:
These are available under Repository Settings->Workflow->Branch Permissions
I've been using Bitbucket for a week now. It seems like a capable platform. Personally in my development activities, I keep a daily "journal" of whatever I need to keep track of separately from any commits to the Git repo. It gives me a place to keep all my "thoughts and ideas" in one place.
Before I end a day's work, or I jot down what I last worked on and any thoughts I think I'll need on the following day. And before I begin each day's work, I just flip to the last page of my journal and it quickly brings me back up to speed of where I was at yesterday, no matter how little sleep I got. :-)
I see Bitbucket has "Comments", "Work Log", "History" and "Activity", but they seem to be tied only to user stories, todos and the like.
Does anyone know of a way where I can have something like a "Work Log" tied directly to my user account? I'm thinking I could use it for my personal "Journal".
Note: I'm using a locally installed Bitbucket server.
If you're using the online https://bitbucket.org (not specified in the question) rather than a hosted instance then you can do a couple of things.
1 Wiki
Create a repository which will act as your work log
Obviously if you want to keep notes with the same code base just enable the wiki for that repository. The question seemed to suggest you may want to be repository/project agnostic
Update the settings of the repository to enable a private or public wiki
This is probably the simplest and richest replacement to your note pad
2 Use a repository
Create a repository which will act as your work log
commit Markdown (i.e readme.md or index.md) files
Note: in the case of a hosted instance this could even be a repository associated to your user rather than a project.
This is very manual, though it does mean you can have an offline version of your "pad" that you can edit/search in your IDE with some IDE autocomplete. Just like the wiki you can use the code backtick escapes with syntax highlighting. Last I checked the these were rendered pretty well in the browser through bitbucket.org as well as any editor/IDE you might use.
Regarding todo's
I've found the best cheap todo solution for me is using a gist as described on life hacker. They are low ceremony and versioned which checks all my boxes (excuse the pun). If you couple that with the above you may actually be able to embed it into your bitbucket wiki, though I've not tried.
If you are using JIRA and Bitbucket already, maybe consider Confluence? Confluence has some convenient and easy to manage TODO functionality and it lets you expand on those thoughts with all the power of a wiki when you are done.
I keep a "TODO" page and additionally put the checkbox on any tasks in other pages. They are all aggregated together in a tasks view.
See:
https://confluence.atlassian.com/conf54/confluence-user-s-guide/managing-changes-and-notifications-and-tasks/managing-tasks-in-confluence
With my information, non-admins may not create a new branch. However, is he/she creates one (or gets it created by taking help of someone admin), he/she would still need to get every commit reviewed before merging into branch. Can we avoid this kind of a scenario where pushing something into a less important branch need not go through review process (without making someone an admin)?
I think you should create a subset of branches/references and give permission where everybody can create such branch and can push commit directly.
So create a new reference like refs/heads/feature-[a-zA-Z]* and add Create Reference, Push - with Force Push option to able to delete branches, Push Merge Commit
you can find more info about Access controls there.
I'm trying to switch from SVN to TFS, and I'm wondering if there's any way to manually set the TFS Changeset ID to match my SVN Revision number. I have a few internal tools that perform some automated tasks based on the SVN revision, and they're all going to stop working if the revision number changes from 2,050 back down to 1.
I'm sure this isn't really the optimal way to handle these internal processes, but it's working for us and we'll probably only be using these tools for the next 12-18 months, so I don't really want to rewrite them. Any ideas would be appreciated.
I doubt that you get to set TFS changeset IDs. However, usually when migrating between source control systems, you use some tool/script that migrates the history, creating checkins that match the original checkins in content (not in IDs though), and that might set the changeset IDs more to your tools' liking.
It's controlled by the in tbl_ChangeSet.ChangeSetId field in the collection DB. It's an hack but you should be able to drop the primary key constraint, assign it with any value, and set back the primary key.
A safer approach would be creating a custom Check-In Note ("SVN Revision") for storing the original revision numbers.