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.
Related
I would like to set up a Jenkins based CI system, where the job histories are dynamically managed based on the parameters coming from webhook triggers.
Currently, I can only trigger specific jobs, maybe with applying filters, but it will not handle jobs dynamically.
I aim for a solution, where a parameter (or group of parameters) identifies a job with its own history. If the job history does not exist, it is created automatically.
In the results, I would like to somehow mimic the behavior of the GitHub PullRequest plugin. The problem with it, that it is tightly coupled with GitHub but I need a more generic solution.
I see two marginally different solutions here:
Manage jobs
Jobs can be managed based on the build parameters. The jobs dynamically created and deleted.
Filter builds
The job remains the merged job containing all the Pull request for all the branches, and some UI features able to filter out the different histories from it based on the parameters.
I do not know if any of this is achievable with currently available Jenkins plugins, or if I have to implement something from scratch?
Thank you for any answers!
Actually, I was looking for the Multibranch Pipeline approach, just I didn't know about it yet.
That is actually doing the same that I described for GitHub and BitBucket.
I was lucky as my target was BitBucket.
In our existing CD pipeline there is a manual step to push from test to production. Furthermore only certain persons can authorise this. We control this through Jenkins freestyle jobs in views with certain users having permissions to different views.
Now we are thinking about using Jenkins pipelines. There is an input step for a user to manually approve the go ahead to the next stage.
Is there a way to control who can perform the manual input? Alternatively, is there an API for progressing the pipeline, in which case we could build the tooling to let relevant users have permission.
Research
This SO post suggests it's not possible to do the API call.
This Jenkins issue tells me there is no ability to resume a pipeline that is stopped because of a failure
So far it's looking like a resounding "NO" to authorisation of manual step and progressing via API. Any other ideas appreciated.
From the documentation that you linked to, there's a submitter parameter where you can specify the allowed users/external groups allowed to respond to the input, which sounds like it should be what you're looking for.
submitter (optional)
User IDs and/or external group names of person or people permitted to respond to the input, separated by ','. If you configure "alice, bob", will match with "alice" but not with "bob". You need to remove all the white spaces.
We have 'try' build jobs that developers can initiate with parameterized variables to point to a particular branch for pulling the code and trial running the build in jenkins. Is there a way I can customize a custom personal view showing only the builds that I have started?
The custom way
I think there's a way to customize a personal view by coding / modifying your Jenkins installation, jan-molak worked on that feature here.
You can check the commits and maybe implement something by your own, especially this and this.
The plugin
Take a look on View Job Filter If you configure it, there are options which seems to acomplish what you want:
Logged-in User Relevance Filter: This adds/removes jobs based on their
relevance to the logged in user. For example: matching jobs that were
started by the user, or where the user committed changes to the source
code of the job; matching jobs with a name that contains the user’s
name or login id.
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
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.