I am trying to use travis for continues integration with github. I want to create a custom deploy on new tags. The problem is I can not get travis to kick of the build when I create tag.
I believe an alternative would be to create a release branch...
my travis.yml looks like this
language: node_js
node_js:
- "0.10"
# whitelist
branches:
only:
- master
after_success:
./build/update-ghpages.sh
Here's a few things:
Are you pushing your tags to github with git push --tags?
Are you pulling your tags on travis-ci with git fetch --tags?
You branch white list could also prevent tagged builds from running, as they could be blocked for not being master branch.
Are your tags based off branch master? If so then the last comment shouldn't apply, as the tagged commit should still be built from the commit on master and your deployment program will still recognize it is a tag if git fetch --tags is performed.
If none of these suggestions help you I'll be happy to take a look at your setup if you give me a link to your travis-ci build.
Safelisting also prevents tagged commits from being built. To allow tags trigger the build consider adding tags to the whitelist with regular expressions, for example /^v\d+.\d+(.\d+)?(-\S*)?$/ if you use v1.0 naming pattern
For additional information go here
Related
I'd like to check code formatting when publishing new branch.
My situation is as follows.
I checkout new branch (ex) branch-0XX ) based on develop branch
I added some features and pushed those remotely (branch-0XX)
I liked to check code formatting before requesting pull request to merge branch-0XX into develop branch.
I tried to use Github webhook to trigger a event when a new branch is created and I did it. However, the name of newly created branch is not static and I'm not sure whether it is possible to run jobs based on git action yaml file because I think the name of branch is added on yaml file.
I'm very new in Github and please let me know if you need further information.
You will want to use the push event in combination with branch filters filter out your develop branch.
on:
push:
branches:
- '*'
- '!develop'
I am currently trying to implement an automated release GHA. One of the main features is that it will generate release notes based on previous tags. For some reason every time I generate release notes, Github will populate the release notes with every single branch that has been merged into the branch that I am creating release notes for. It should only be creating release notes for branches that have been merged between tags.
For example, I'm upgrading my repo's version from tag v1.1 to tag v1.2
When generating release notes it will pull in every merge from the branch I am adding a tag to since the beginning of the entire repo. Instead it should only pull in merges since v1.1
I think this might have to do with the fact that my tags aren't properly attached to branches. I am using this command in my GHA action script to get my previous tag.
git describe --tags --abbrev=0
This returns:
fatal: No tags can describe 'ExampleGitSHA'
It seems that GitHub is not recognizing my previous tags for whatever reason.
Following actions/checkout issue 701, check if your git describe --tags --abbrev=0 fails because your GitHub Action did not fetch any tag.
If that is the case, add a step after the actions/checkout:
- name: Checkout
uses: actions/checkout#v3
- name: Get tags
run: git fetch --tags origin
I am creating a new git workflow. And just like any other piece of code, I want to test it separately without having to merge it into master first.
This will also help if I have to make few corrections if something doesn't work in the workflow yaml.
Here is the mechanism that I am looking for:
main branch has .github folder which contains all workflows
I create a branch and add my workflow to .github folder
Now I should be able to see(somewhere on Github) workflows from my branch running
When I know that workflows are working fine, I merge my branch in master
Now under github 'Action' tab, new workflows will reflect
Is there a way to do this?
I am actually doing workflow testing all the name, as you can see this test workflow workflow-level-notification is not merged into master branch (ie default branch), and I can still see the workflows in the UI.
Like GuiFalourd said, you can also use act to do the local testing as well. But working directly in the github repo is not that bad. (you can delete the workflow after)
If you would like to test non PR triggerd actions you can simply update your default branch temporarially, run the actions for test, then when you are done switch back.
I am trying push my changes into gh-pages/index.html but it was failed,
The PR located https://github.com/bulkan/robotframework-archivelibrary/pull/20
However travis-ci documentation https://docs.travis-ci.com/user/customizing-the-build/#Building-Specific-Branches
By default, the gh-pages branch is not built unless you add it to the
whitelist.
I don't exact reason why travis-ci is started building gh-pages, do i need add .travis.yml to gh-pages or are there anythin i was missed here https://github.com/bulkan/robotframework-archivelibrary/tree/gh-pages
It looks like the build that failed was run on a different branch named doc-update, which we wouldn't block by default, as it's not named gh-pages
What we can do this by enable our setting to only run builds on branches that have a .travis.yml file on them, shown in below screen cast
To put it in "BDD" terms:
Background:
Given I'm contributing to a GH repo
When I create a pull request
Then Travis should build the latest commit
When I push to an existing pull request
Then Travis should build the latest commit
When I merge a pull request to master
Then Travis should build master
I was confused by Travis-CI's "build pushes" and "build PRs" settings, as:
Enabling both causes each Pull Request to be build twice by Travis
once for the commit on that branch
and once again for the merge commit of that branch into its destination
Enabling just "build PRs" causes PRs to be built, but doesn't result in post-merge builds (i.e. on master).
Enabling "pushes" brute-force satisfies the above criteria by building all pushes to the repo. You can try to finagle things by white- & black-listing branches, but that will probably bite you unless you're rigorously disciplined with branch names.
This is explained more in Travis-CI docs and GH issue #3241.
Anyone know a configuration that satisfies the above criteria?
I eventually found another GH issue (#2111) which gave me the idea to try enabling both PRs & pushes, but with a whitelist to restrict pushes to a specific branch. This seems to satisfy the criteria for my workflow. Here's what I did:
Enable both PRs & branch pushes in the Travis settings for the repo:
Change .travis.yml to white-list master branch (i.e. only build pushes to master):
branches:
only:
- master
Test it by creating a PR with the .travis.yml change, and another PR with some empty commits to verify it works for forks too.
Verify successful merge commit build from master.
Just found in travis docs
Add to .travis.yml
if: type = push
alternatively:
if: type = pull_request
Assuming you want to build all PRs, something like the following will do the trick. Enable both branch and PR builds on the settings page, and put this line as the first line in your travis.yml:
if: (type = push AND branch IN (master, dev)) OR (type = pull_request AND NOT branch =~ /no-ci/)
This will attempt a push build on all pushes and a PR build on all pushes to an open PR, but will filter out any that don't meet the condition. You might need to modify this a bit - the clause about not building branches with no-ci somewhere in their name is obviously optional, and you may not have two branches that you always want to run builds on.
You can read more on conditions and conditional builds on Travis's site.
The whitelist approach described in the accepted answer has some significant limitations. In particular, it doesn't support non-redundantly building arbitrary branches without opening a PR.
I opened an issue asking for a better solution.
You can use next workflow if you want to test not only master branch but some others branches too:
Keep both "Build pushes" and "Build pull requests" ON
Add branches:except directive to your .travis.yml:
branches:
except:
- /^pr\..*/
In this configuration:
any commit to branch feature-A will trigger the build
any commit to branch pr.feature-A will not trigger the build
if branch pr.feature-A is used in opened pull request then build will be triggered
Workflow example
temporary WIP branch shared between several developers: wip.feature-A, any commit to this branch will trigger the build
when branch is ready to be merged to master you can rename it from wip.feature-A to pr.feature-A and open pull request
if while reviewing pull request you want to apply new fixes, just push to pr.feature-A
On all the steps above only one build will be triggered.
For one of the repositories, I was working with, here is what I wanted:
There is an origin repo which is the main repo which does all the releases.
I wanted that all the pull requests coming to master branch of origin should be built with Travis only once irrespective of the fact that it comes from a forked repo or any other branch of the origin itself.
For this case, this works like a charm
if: (type == push) OR (type == pull_request AND fork == true)