Im wondering if theres an easy way for me to take advantage of husky (or just git hooks in genral) to both restrict PR's that dont have a specified Azure Devops PR tag before a commit is even made.
i.e. when committing the developer would have to type
AuthMicroservice: Added option for google OAuth
or
MainFrontend: Gave up on react and decided to reimplement everything in coffeescript and jquery.
In doing this the keyword before the : would be from a list of possible tags and when committed, ('or pushed') it would add the tag to the PR (assuming it exists, if not add the tag when the PR is created, again through husky)
I only have experience using husky to auto increment package numbers with standard-version so wouldnt even know where to begin on this, I cant seem to find much online
Related
In our Github organization, we merge everything to develop. Once a week we merge everything from develop to master. We want to have a list of all issues in the PR description based on the commits, which are linked to the issues (with #number of issue).
We have a Github Actions workflow that automatically creates the master PR. This PR usually has a lot of commits. We try to find a way to automatically write a comment with the titles of the issues which are referenced in the commits!
I tried to use the Github REST API but Im way to unexperienced with that so nothing seemed to work. I also tried to use some github changelog tools like this and this and tried to add them to a github action worklow, no success. Im also pretty new to github actions and coding in general.
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.
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.
Bitbucket has a feature to exclude files from the new pull request and I'm wondering if there is a similar feature in GitHub?
Scenario:
I have a Branch A that has changes in .travis.yml I pushed those
changes and create a PR I need to merge all changes in this branch
except the changes in .travis.yml file.
No, there is no such feature in GitHub (to the best of my knowledge confirmed by a quick google search).
The best alternative, excluding the proposed duplicate question for using a workaround, is to refer to this blog page, stating that:
Previously, if you wanted to use GitHub to remove files from a pull
request, you’d need to switch to the pull request branch and look for
the individual file to delete it. Now, if you have write permission,
you can click on the ‘trash’ icon for a file right in the pull
request’s “Files changed” view to make a commit and remove it.
I haven't tested this method, but I feel like it is somehow related to the rejected "alternative workaround".
I have a repository which contains a badge from Travis-CI. This badge is included in the Readme.md with the following link, as suggested by Travis-CI documentation:
[](https://travis-ci.org/nikicc/orange3-text)
However, now everyone that forks my repo will got the links to my Travis-CI badge, since it is hardcoded along with my username. I would like to achieve that all forks automatically have the links to theirs badges, not mine. Is it possible to somehow bypass this by using some variable for the username of the repository inside Readme.md files on Github? Is there any nice solution for this?
There is an alternative way to make it work:
Github: Can I see the number of downloads for a repo?
(https://github.com/andry81-devops/github-accum-stats)
It can be adopted the same way for an external service or site with data. All you need is to write a shell or any other script and call it from the github workflow action (.github/workflows/blabla.yml file).
The only thing can be a problem here is the GitHub workflow pipline call frequency, which might has a limit something about 1 call per 1 hour or 15 minutes (I didn't test it).
The idea is the same - store the status in a separate repository and does update it from a GitHub workflow action. Later you can use another action to rewrite the statistic repository below the head commit to cut off the history of changes if not need it.