I was trying to push to a new branch and submit a pull-request to
msgraph-sdk-java
https://github.com/microsoftgraph/msgraph-sdk-java
in order to add some improvement but I am getting 403..
How to submit a code to Microsoft Graph Java?
On Github, you create a fork of the original repository, make your changes and then create a pull request from your fork to the original repository.
You are generally not allowed to create new branches on repositories you are not maintaining yourself.
Related
I have a GitHub action workflow that outputs a number and I want to display that in a badge.
Using https://github.com/username/reponame/actions/workflows/myaction.yml/badge.svg I get a red or green failing/success badge but I want to display the number of failures instead, which the workflow outputs into the "errors" output variable.
How can I access that variable in a badge?
There are few options in Github actions marketplace
Bring Your Own Badge - https://github.com/marketplace/actions/bring-your-own-badge
BYOB is a GitHub Action to create badges dynamically based off of GitHub Actions' results, allowing for extremely versatile and easily-maintainable badges.
If you want to use https://shields.io/, consider Dynamic Badges - https://github.com/marketplace/actions/dynamic-badges
This action allows you to create badges for your README.md with shields.io which may change with every commit. To do this, this action does not need to push anything to your repository!
In a subsequent job (step) in the same workflow you could.
I think you want to use your own badge using e.g. https://img.shields.io.
I image you will update e.g. the README file every time the actions are finished, the updating step will be part of the workflow. The transfer of output could be done like here Using output from a previous job in a new one in a GitHub Action.
You will append e.g. the README with a proper svg [](some url).
I created an action to generate a badge from a workflow:
Build-A-Badge - https://github.com/marketplace/actions/build-a-badge
As other users have pointed out, I didn't want any external dependencies or to create new branches on the main repo. So the workaround I used is to store the badge data in the Wiki, which is a separate repository.
We have a workflow that runs whenever a tag with a specific format is pushed to the main repository. Originally, the displayed name is consistent with the name: entry at the beginning of the workflow file, but this is no longer the case.
Before this change, we had a separate repository with a cron workflow that ran a python script to push the tag to the main repository, which triggers the workflow there.
We recently moved to using a workflow from the main repository to push the tag, and this is when the different workflow display name changed. There are some differences between the two triggering workflows. The old trigger ran a python script which presumably pushed the tags "from" the script. The new trigger explicitly calls git push --tags from the workflow file itself.
I believe the move to the new trigger is why the display name is changed, but I cannot be certain.
I'm just playing around with the bitbucket/mercurial pull requests feature, and either something is behaving strangely, or I'm doing something profoundly stupid.
I (theukdave) am the owner of a repository 'RepoA' which was created under a 'team' (which I gather bitbucket doesn't really have anymore). Let's say this lives at bitbucket.org/team1/RepoA
So I created a fork of that repository under my own username and called it RepoB. So now there's a fork that lives at bitbucket.org/theukdave/RepoB
I then create a test commit on a branch off our main development branch 'develop', and then merged that new branch back into develop. I pushed up to bitbucket.org/theukdave/RepoB, and then created a pull request from 'theukdave/RepoB develop' to 'team1/RepoA develop', I add a title and description and NO reviewers (since I'm just testing right now) and click the 'create pull request' button.
A few moments later, the test commit and merge from RepoB is showing up in my RepoA. The pull request is there, I can see it, I have not yet approved it, but the commit and merge and available to all users of RepoA. Even if I decline the pull request, the test commits are still in RepoA.
Is this because I'm the owner of RepoA, and so my pull requests are automatically merged in? Is it because I added no reviewers? A combo of both? Or am I missing something here ...
First of all really interesting. You can resolve this situation using this steps.
To disable automatic branch merging for all repositories in a project (requires project admin permission):
Go to Project settings > Branching model.
Select Disable automatic merging, then click Save.
I hope useful for you.
I'm a complete noob at Mercurial API and Python, but I'm trying to write a useful extension for myself and my colleagues now.
Let's assume I have a repository which contains some code and an auxiliary file .hgdata. The code and .hgdata are both under Mercurial's control. When I execute a command pull-extended which is provided by my extension, I want it to make a pull and then to analyze the state of a .hgdata and probably make some additional actions. The problem is that when my command is invoked, it just pulls the incoming changesets, but it can't look into the actual .hgdata without making a preceding repository update. Is there any way to watch the after update .hgdata besides repository update?
I've received an answer on the Mercurial's official IRC channel:
In order to get an actual file state after making a pull, we may use repo[revision][file].data().
P.S. I haven't checked that yet. If it works, I will close the question.
I'm using perforce for versioning control. Let's say I am working on a file in the main branch:
//main/xx.cs (it's open for edit)
In the mean time, //main gets branched to //v1 and then //main gets locked.
Is there a way I can integrate my local changes in //main/xx.cs directly to //v1/xx.cs ?
There's a similar question: Can I integrate checked out files into a different branch on perforce
One of the answers there gives:
http://kb.perforce.com/UserTasks/CodelinesAndBranching/BranchingWorkInProgress
which looks like it will provide more than you need.
There is also various p4shelve, p4tar options that might help:
P4 Shelve Python addition for any version of Perforce
P4tar offline (or at least off-server) saving of changes
p4 shelve 2009.2 and later Perforce feature to provide built-in shelving.
Here's one possibility...
Sync //main to the changelist where the branch was made. Resolve conflicts.
Important! Sync //v1 to the same changelist.
Open //v1/xx.cs for edit.
The ugly part: manually copy the local copy of //main/xx.cs over the local copy of //v1/xx.cs
Sync //v1 to head and resolve conflicts.
Submit changes.
Voila!