I have a GitHub action that evaluates something and then creates a Status Check with the result.
setup is the one that evaluates and linting is the result (a different status check with all the information). This is done because the default status check is only the logs, but if I create a second one, I can format it with Markdown.
The problem I have is that, when the action is executed to the same commit (because the Pull Request was modified by changing title, reviewers, etc) the action is executed again, which is intended, but creates a second setup check that doesn't disappear. This will accumulate for as many modifications I make.
The old linting status check, instead, will be replaced by the new one, so I don't have any problem with that.
Is there any way to hide the setup check once it's completed? Or to completely hide it? I would prefer to show it while it's running, but once it's finished it should hide itself to keep the PR clean.
This appears to be a bug. Your best plan of action is to contact support#github.com regarding this bug. Make sure you mention how to reproduce this bug (or even link them to this SO post).
As this doesn't appear to have any adverse effects (other than potentially cluttering the screen), it shouldn't be that big of a problem, but I'd definitely reach out to Github.
Related
I am currently attempting to build a small program, that, using the Github API would make a small change to a file in a repository, add a tag to the commit that change belongs to, then points the HEAD of the branch to said commit, which would then trigger Actions, after the entire operation has completed. I noticed, however, that when I tested my code, the commit would show up, but there would not be a tag visible anywhere. I made note of the fact that the API was, in fact, receiving the request to set the tag, and there it seems to have gone through, but not on the repo itself it seems.
For reference, I was following this tutorial, and then adding this call after step 4.
Any help would be very much appreciated!
I would like to make a pull request from my fork repo to the upstream repository.
As always I was following these steps here from the guidance from Github.
But this time I can not make a pull request, as the button is disabled.
The branches can be automatically merged.
I do have changes in my forked repo and I can see commits made.
Base repo and head repo are indicated correctly.
In my case, the pull request Title field didn't auto-populate like it usually does. Once I typed in a title, the button became active.
From Github Developer Support:
Also, I know this might seem strange, but could you try selecting the
base repo/branch from the drop down list (even if this already seems
selected), and give this another go. It could that, for whatever
reason, the pull request creation flow isn't picking this up
implicitly.
I have also logged out and logged in again.
After that, everything was fine!
make sure to put something in the title, I forgot to add one here
Populating the "comment" field did it for me.
I couldn't see a button at all... and then I realised...
I wasn't logged in #facepalm
It happened to but I realized that and immediately changed the default branch to master. The pull request button got activated thereoff.
After realising it's just a HTML issue, I enabled the button by inspecting the element and deleting the tag in my browser (Safari).
That should fix the issue in other browsers too.
I had to select my branch from the list shown down on the github page labeled "There isn’t anything to compare." - weird but worked fine.
I had the same issue. Adding a title to pr fixed the problem
On a Github project, I see a guy made a pull request in Pull Requests section, but I find he made many mistakes so his code need to be corrected. Instead of asking him to change his code, is it possible to do it by myself (that is, I want to correct his code by myself)? and how?
I'm also a member of that project, and I'm new :)
Enabling repository maintainer permissions on existing pull requests
Pull request creators can give these permissions on each of their pull requests when they initially create a pull request from a fork or after they have created the pull request.
On GitHub, navigate to the main page of the upstream repository of your pull request.
In the list of pull requests, navigate to the pull request that you'd like to allow commits on.
In the right sidebar of your pull request, select Allow edits from maintainers. You can change these permissions at any time by unselecting this option.
More details on github help page: Allowing changes to a pull request branch created from a fork
TL;DR
Author of PR can modify an existing pull request to let repository maintainers make commits to your branch.
In order to allow you to make commits to others PR - the author has to set checkbox from the left:
Assuming the original author is responsive enough, it’s always better to ask them to fix it (unless the change is an obvious typo fix, maybe). They might have a reason for writing it the way they did.
If the author isn’t responsive and you’re deciding whether to fix it in place or with a new commit, ask yourself which way the history reads more clearly. If the commit would introduce a regression, you should probably fix it in place (to avoid breaking bisectability). If it handles some cases and you just want to add more cases without significantly changing the existing code, it might be better to add a new commit.
If you do amend the existing commit in any way, make sure to leave a note in the commit message explaining what you changed. One typical style is to leave a note in square brackets, grouped with any Signed-off-by: lines (if applicable):
[your.email#example.com: Refactor new cases into a function for clarity]
For example: linux.git commit b44129b3.
via https://www.quora.com/GitHub-Is-it-bad-etiquette-to-change-someones-pull-request-before-committing
What do you think is the best practice for checking in code from multiple files that implement multiple changes, but are ready to go in at one time?
Do you check them all in at once, keeping the checking reasonably atomic, and put the changes in one long comment?
Do you check in the files in groups so the right comment is associated with the right file?
Do you have tools which let you check in at once with different comments on different files?
Check all at once. If you check in groups you make break the build.
But it is better to check in as you get the change done.
I use Git, which allows you to easily resolve the tangled working copy problem. I can work away without worrying about which changes are related to what, then after I've done a few things step back and commit each logical change individually, with its own commit message.
This method is great for keeping small, logical changes together. If I look back at the history of a file with git annotate, I can easily see why each change was made without having one commit covering a whole bunch of unrelated changes. Furthermore, as somebody else mentioned, having smaller commits makes it easier to roll back a previous modification if you change your mind later.
So long as their aren't dependencies among multiple changes, keep your check in's small. Check in the smallest collection of changes that won't break the build or introduce other problems.
For bugs or small change request, usually one check in per bug (or change) tends to work best. This allows you to easily identify which file (or files) were updated to address a particular issue. this is not only helpful in rolling back changes but also in determinie what changes were made to fix an issue should a similar problem arise in the future.
For major changes, if they can be broken down into smaller units of work to be checked in, do so. A - if you do need to roll back something because of a minor mistake, having to rollback all of the changes is just plain depressing. B - hard drives crash - if you are working on something for an extended period of time, the more changes you implement and the longer you work without checking in, the greater risk you are putting your work and your organization in.
I try to keep each check-in related to a specific ticket number, project, etc.
Keeping checkins as small as possible is good practice for a number of reasons, especially if you want to roll back anything. For this reason, try and check in code in the smallest "meaningful" increments possible (as long as everything still compiles after each checkin).
What template do you use for comments on code commit?
One example of a template is:
(change 1): (source file 1.1, 1.2): (details of change made), (why)
(change 2): (source file 2.1): (details of change made), (why)
Ideally each change should be mapped to an issue in the issue tracker. Is this template alright?
Here are my thoughts... all these will be open to interpretation depending on your particular development methodologies.
You should be committing fairly often, with a single focus for every commit, so based on that, comments should be short and detail what the focus of the commit was.
I'm a fan of posting the what in your comment, with the why and the how being detailed elsewhere (ideally in your bug tracking). The why should be the ticket, and upon closing the ticket, you should have some kind of note about how that particular issue was addressed.
A reference to your bug tracking system is good if it isn't handled otherwise (TRAC/SVN interaction, for example). The reason for this is to point other developers in the right direction if they're looking for more information on the commit.
Don't include specific file names unless the fix really complex and detail is needed. Even still, complex details probably belong in bug tracking with your implementation notes, not in version control. Files edited, diff details, etc, should hopefully be included with version control, and we don't want to spend time duplicating this.
Given these ideas, an example commit comment for me would be something like
Req3845: Updated validation to use the new RegEx validation developed in Req3831.
Short, communicates what was changed, and provides some kind of reference for others to get more info without hunting you down.
I prefix each paragraph with + - * or !
+ means its a new feature
- means feature is removed
* means feature is changed
! means bugfix
I don't think you should commit detailed description about what parts of the code are changed, because that's why every VC has diff :)
If you use a bug tracking system, include relevant ticket numbers.
You do not need to mention changed files, or your name. The source repository can figure that out by itself. Describing the changes also only makes sense if it is not non-trivially obvious from the diff.
Make sure you have a good first line, because this frequently appears in the change history view, and people need to find things by this (the bug tracking ticket number should go there, for example).
Try to commit related changes in a single changeset (and split unrelated changes into two commits, even if to the same file).
I try to follow the same rule as for code comments:
Explain the WHY, not the HOW.
IMO a comment should contain a reference to the issue (task tracker, or requirement). Which files are affected is already available from the version control system. Apart from that, it should be as short as possible, but still readable.
I try to keep my fixes in separate check-ins.
I don't use an actual template, but a mental one, and it's like this.
Issue - dev level summary of
issue.
The issue tracker has all the management details, and the changes/diffs can be reviewed for code changes, so the comment is for dev's to understand the why/what of the issue.
Here's what I've seen used successfully:
Reference to bug number or feature ID
Brief description of the change. What was changed.
Code reviewer (to ensure you have one) unless handled by the checkin system.
Name of tester or description of which tests were run (if late in the process and you are being extra careful)
I use the simple technique described by Chaosben on the JEDI Windows API blog.
In order to get a fast view on the
changes made to a repository, we
suggest to write brief concise
comments starting each line with one
of these chars:
+ if you added a feature/function/…
- if you removed a feature/function/bug/…
# if you changed something
Doing it this way, other developers may find the desired revision much better.
First, commits should solve one single problem (separate commits for logically separate changes). If you don't know what to write in the commit message, or the comit message is too long it might mean that you have multiple independent changes in your commit, and you should split it into smaller items.
I think that commit message conventions expected and used by git makes much sense:
The first line of commit message should be a short description
If appropriate, prefix mentioned above summary line with subsystem prefix, e.g. "docs:" or "contrib:"
In next paragraph or paragraphs describe the change, explaining why's and how's
Keep in mind that if someone needs details of what changed, they can get a diff. That said, I just usually write a sentence or two for each major change, and then lump any minor fixes at the end.
There is no hard and fast rule as its plain english. I try to explain the work done in minimum words possible. Anybody looking for history of changes just want to know what happened in a particular change. If anybody is after more details then its there in the code.
Second thing I follow is if there is any bug associated then stick that in or if its related to any dev task then associate that with the change.
If two files were changed for different reasons, they should be in different commits The only time you should commit more than one code file at a time is because they all belong to the same fix/change