I want to use travis-ci to run a script and commit the result back to the same branch on github. (The script generates a markdown table of contents, but could be anything really). Obviously this causes an issue as travis will then see a new commit and run again ad infinitum. I tried to use
if: sender != "Travis CI"
In my .travis.yml, but the docs are extremely vague about what exactly 'sender' is matching against, and I see no way to inspect the run time values travis is using.
I use this method: https://gist.github.com/willprice/e07efd73fb7f13f917ea
to commit back to github.
Is there a better way to achieve what I want? Or what is the correct way to make this work with travis?
There might cleaner ways of doing it but one way is to use the following.
According to this documentation, you can simply add a "tag" or specific string to your commit message in order to avoid Travis building it.
Simply add [ci skip] or [skip ci] to your commit message and Travis will ignore it.
Your function in push.sh will become the following:
commit_website_files() {
git checkout -b gh-pages
git add . *.html
git commit --message "[skip cp] Travis build: $TRAVIS_BUILD_NUMBER"
}
Also you could still push to another branch which wouldn't be watched by Travis.
Hope this helps.
Related
I am newbie using Gerrit review flow and previously had good experience in GitHub and GitLab.
But looks Gerrit review system works bit different.
So I have created one feature branch called feature/test. This branch contains one test commit and this commit has been pushed to Gerrit.
Change can be seen Gerrit with unique change id and commit.
Now the problem is, on this feature branch 3 developers will work and they need to continuously fetch each other changes with same change id.
Can someone help on this, what I need to do. because when I pulled this feature branch with one test commit then change is not visible to me at different place.
I didn't understand what you mean by "fetch each other changes WITH SAME CHANGE ID". A Change-Id is a unique number that identifies a change in Gerrit. Each change made by each developer will have different Change-Ids.
The better process to work on Gerrit is the following:
1- Update the local repository
git fetch
2- Create a work branch based on the remote branch:
git checkout -b work1 origin/feature/test
3- Make your change and commit
git add
git commit
4- Push your change to review on Gerrit:
git push origin HEAD:refs/for/feature/test
If the reviewer suggests something to do:
1- Checkout the work branch
git checkout work1
2- Fix your change and commit
git add
git commit --amend
3- Push the fix to Gerrit:
git push origin HEAD:refs/for/feature/test
All developers can work in parallel using the same process. You can also work in parallel by creating other work branches (work2, work3, etc) while is waiting for review. Avoid serializing the commits by always basing your work branches in the remote branch and not in your previous work branch.
When the feature branch is read, it can be merged in the master (main, release, or whatever it is called) branch.
I'd like to know how to proceed in GitHub where I could to be able to get the updates from the original repo but prevent opening a PR after each time I push a change made by myself?
The concept I want to apply this is to use a blog template for my GitHub pages. I'd like to get the feature for the future if the contributors would make any but at the same time, I'd like to prevent pushing anything to the original repo as a PR since those commits wouldn't include anything related to making a contribution to the project.
PRs aren't generated automatically, you need to explicitly create them from a branch.
You can fork a repo and work on it, and when needed, fetch and rebase from the original repo you forked from. As long as you don't explicitly use this repo to create PRs on the original repo, you should be fine.
EDIT - Adding some details as per the last comment:
Assume there's a repo called something owned by someone. You can start off by forking it to youruser using the GitHub UI. Then you can clone your fork and work on it:
git clone https://github.com/youruser/something.git
In order to get the recent changes from the original someone/something repo, you need to set it up as a remote. By convention you'd call this remote your "upstream", but you can really give it any name you choose:
git remote add upstream https://github.com/someone/something.git
Once you've added it as a remote, you can fetch from it and rebase on top of it:
git fetch upstream && git rebase upstream/main
(note that using the main branch is just an example. You can of course rebase on top of any branch in the remote repo)
I think it's not possible because when you clone or fork that repo, from that time, you start to add your own content to it since it's your personal blog. So you cannot keep getting the features from main repo. Maybe you can try rebase but I'm not sure if it works for this case. Or you can add those features to your repo by your own whenever you need them.
I'm trying to learn how to use GitHub Actions and I'm running into a small issue. When I run the code locally, the files created while python training/train.py is running are created in the correct folder. However, when I try to do the same thing with GitHub Actions, the files are only created when I choose to create them in the root directory rather than /training/outputs/. Is there a way to resolve this?
Here's my GitHub repository: https://github.com/JayThibs/github-actions-ml-template
I've figured out how to resolve this so I figured I should share here.
Since I am using CML (Continuous Machine Learning), I could simply include the following line in my GitHub Actions cml.yaml file:
cml-pr training/outputs/*
This is because cml does not push outputs to my code automatically.
Besides using cml-pr, you can also use the following github push manually:
git config --local user.email "action#github.com"
git config --local user.name "GitHub Action"
git add training/outputs/*
git commit --message "Commit training outputs"
git push
Please keep in mind that the latter solution won't handle merge conflicts gracefully if there is a race condition between several simultaneous runs.
Since the action will push files to your repository, it will trigger another GitHub Action if your action is triggered on push. To resolve this, simply add something like [skip ci] in your commit message and GitHub will prevent an action to be triggered. You can learn more about it here: https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/
0x2b3bfa0 on GitHub helped me resolve this issue, you can find our conversation here: https://github.com/iterative/cml/issues/658
Is there any way to have the full source code repo after each commit?
I mean for example using
https://api.github.com/repos/highcharts/highcharts/commits
would give me a list of commits, but I want to realize what was the effect of that commit to whole repo (I want to check whether any code duplication is added to whole project or not using some automatic tools). Is that possible?
I want to see the code effect, so having repo even after merging each commit would be fine.
Simply implement a listener to a webhook (see "Creating a Webhook"). Set it up to ball your listener at each push event.
You can then do a pull when called by the webhook, and get a fresh updated copy of the repo locally.
For other repos you don't have any control or whose owner is in your team, that webhook approach is not possible.
You would need to implement a scheduled polling approach, through a regular cron job for instance.
That would possible multiple commits, so you need to wrap that pull with a git log as in here.
git checkout master
git fetch
refs=$(git log --format='%H' ..origin/master)
for ref in ${refs}; do
# do your analysis commit by commit
done
git merge origin/master
Is it possible to pull changes for just a single branch vs. the entire repository. We have parallel development on different branches and do not want changes from another build in the log.
hg log -r %baseversion%:%releaseversion% --style changelog >> hglog.txt
I tried doing this this way but it pulled every change between the base tag and the release tag.
If you're using proper hg branches, then you should be able to use the --only-branch option:
hg log --only-branch my_branch
That will show the changesets only for a given branch.
Edit: Looks like "--only-branch" is deprecated, but depending on the version of mercurial you use it will still be there. See https://www.mercurial-scm.org/repo/hg/help/log . If your mercurial is too new, you may only have the "-b"/"--branch" option.
Also, to show logs only for current branch, ou can use dot instead of current branch name hg log --branch .
Follow-up #criswell
Funny, hg help log know nothing about "--only-branch" option, but note -b|--branch BRANCHNAME
Also, for worst cases, branch() function in revsets