I have a GiHub repository with GitHub actions based workflow (/.github/workflows/build.yml) to do CI builds.
I am from the DevOps team, my case, folks from development team are not allowed to change CI pipelines, they can change whatever they want on a feature branch except “/.github/workflows/build.yml”.
How to prevent a developer changing GitHib workflow to see his app changes passing through different type of integration build quality checks ?
Is there any better approach to achieve this other than options mentioned below ?
1] Through PR reviews
2] Script/automation to validate PR to see if dev did any changes to (/.github/workflows/build.yml
With code owners you can specify who is allowed to modify certain files like so:
# .github/CODEOWNERS
.github/workflows/build.yml #myorg/devops-team
Somewhat off-topic, but note that Toughtworks does not recommend to separate code and pipeline ownership:
[..] in general we find it painful and unhelpful.
Related
We are using Azure Devops to store our repo (Git) and run a pipeline.
The project type is .Net.
On recent PR that trigger pipeline, we noticed the pipeline failed because the developer removed a necessary file (PS script file).
Is there a way to prevent it -> somehow define that the pipeline will always "guard" some files in the main, and not let them be modified from other branches?
You can get really close to your goal by adding a branch policy called Automatic Code Reviewers based on specific files or directories. You can set the reviewer to a specific person or group of people, and any time a PR is modifying the "protected" file(s) the PR will not be able to be completed until one of those people approves the PR. If none of those people approve it the PR will not get completed. The nice thing about this is when you purposefully do wish to modify the file(s), you still can, but you just need to request that a certain group of people also approve the PR.
Tip: I recommend using groups for automatic code reviewers instead of specific people, even if the group has only one person in it. That way an admin can add/remove people from that group as needed, for example when certain people who normally approve the PRs are on out of office. It feels a little cleaner to adjust group membership temporarily, than to adjust the branch policies themselves on a regular basis.
I see this
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github
I want to implement a custom web based github workflow similar to this workflow.
The workflow I have in mind involves allowing a group of developers to help with conflict resolution during a large merge/sync process.
Process involves the following steps. A lot of it will be the existing workflow described above, except that we are looking to do webex integration to notify multiple users and bring them all into helping resolving the conflicts
Create a PR
Start a Sync/Merge from branchA to branch B or Apply a patchfilelargeA to branch B
Collect the list of conflicts and have a conflict resolution page similar to the above link.
Identify the owners of the related change set with git blame
Integrate with Webex to create a Webex space with the list of blame owners so they can help with resolving the conflicts
Let these owners go to this PR, and show them a conflict resolution page similar to the 1 above and have them help resolve conflicts and mark them resolve
Review the resolution/changes
Merge the changes into the target branch.
Questions
Can custom actions like interacting with webex/bot be integrated into the github sync conflict resolution page? and if so how?
If this does not involve 2 branches but instead a branch and a large patch, is there a way to create a customized worklow that will allow that.
Is there any way that let's me restrict merging two branches if one has less code coverage than what is expected? I use jest and added coverageThreshold in package.json file. But even though the coverage was less when I ran coverage, the branch was allowed to merge.
Couldn't find anything in Github settings for branch protection as well.
Branch protection rules are under Settings>Branches for the repo.
To add code coverage requirements, like anything else, you need to add pass/fail statuses to the github actions (or if you use a separate system like Jenkins, that needs to register statuses) and then say that the statuses are required in the rule. Not sure if you can do that on all github plans.
I have confluence page, where I want to store all my feature files(specflow), so that Business can have a look. Currently these feature file resides in a repository in Azure Devops. Is there a way to dynamically link these two , so that Confluence gets updated with the latest feature files ?
Thanks,
Rajee
I have the same basic problem, too. Our code is in DevOps and our product owner needs access to the feature files, but without a higher license in DevOps they cannot see repos.
I submit a pull request even to include new features. I mention the work item Id for the epic, story, feature or bug it pertains to in the commit message. I like to use conventional commits for commit messages in this case:
docs: Cucumber tests for X feature (related #1234)
(where #1234 is the work item Id in DevOps)
Make sure the epic, feature or story is linked to the pull request in DevOps.
Upon completing the pull request DevOps adds a link from the epic, feature story or bug to the pull request, providing some traceability to the real code.
Next, I copy and paste the feature files and scenarios into the acceptance criteria for stories, steps to reproduce for bugs or the description for features and epics. I also include a relative file path in the work item description to the feature file:
(copied and pasted from Project.Specs/Foo/Bar.feature)
Feature: ...
In order to ...
As a ...
I want to ...
Scenario: ...
Scenario: ...
It's a manual process, but you could adopt something similar in Confluence. You might not get the link from the commit to the wiki document, but basically copy and paste is your only free choice.
If your customers have read access to DevOps (which they should) adopting the procedure I outlined above at least gives you some traceability between the work item and a pull request that added the features to the repository. Then it is a manual step to copy and paste the features into the work item descriptions or acceptance criteria so the customers can review and approve. Annoying? Yes. But it does the trick.
I have set up some Github actions workflows in my repo and want to require some of them to pass before a PR can be merged into the main branch. Therefore I selected these actions in branch protection rules, but these do not seem to apply. Only the styleci and appveyor checks are marked as required. All actions are not.
Any ideas what I am missing?
Example PR
Screenshot from settings
Thanks
Seems like Github does support emojis in job names, but does not support matching jobs as required, when there are emojis in job names. Removing the emojis makes the jobs look less nice, but makes the branch protection rules work. 😥