I have repo building in AppVeyor which produces some packages (.nupkg) that are then pushed to MyGet. When I am developing on master everything is peachy, but when I'm on another branch I want it to build but NOT push packages, I have read some documentation on branches and it seems I can have one configuration for master and another for the other branches, however that would mean to duplicate all my configuration except for the line that actually pushes to MyGet. My appveyor.yml file looks something like this:
version: 0.0.{version}
before_build:
- do some stuff (I have about 5 of these)
- ...
build_script:
- cmd: build.cmd
after_build:
- push to myGet
I would just like to run the after_build command if is on the master branch.
Is there a way to run some commands depending on their branch without rewriting the entire configuration for that branch (or branch type or whatever)?
You can use APPVEYOR_REPO_BRANCH environment variable. Please try this:
after_build:
- IF %APPVEYOR_REPO_BRANCH%==master push to myGet
Ilya.
Related
I want to deploy my application in github page. I want the build job to be automated. My build commands basically include running unit tests,building a production version, gh-deploy command to deploy to github page. Can i achieve this using code ship. Do i require a actual vm like ec2 to do this?
The official automation process with codeship involves pushing to GitHub.
If your build process can populate the content you want to publish, then you can simply push it from the codeship job itself.
As an example, see "Auto-deploying to gh-pages with Codeship " (Martyn Chamberlin), which is about publishing a Gulp build:
git clone <the ssh link to your repo> dist
cd dist
git checkout gh-pages || git checkout --orphan gh-pages
cd ..
rm -rf dist/**/* || exit 0
npm install
gulp deploy
cd dist
git config user.email "<the email address you used for your machine user GitHub account>"
git config user.name "<the username you used for your machine user GitHub account>"
git add .
git commit -m "Deploy to GitHub Pages: ${CI_COMMIT_ID} --skip-ci"
git push origin gh-pages
This is a clever little set of commands, really.
It’s creating a git repo inside of another git repo in order to handle the build correctly.
I wish I could say I was the one who came up with this idea but the hat tip belongs to Domenic who gave me the idea with his Travis gist.
A few things to note about this:
This assumes that npm install; gulp deploy is the series of commands you use to combine and minify your assets.
That’s true of my project but yours may be different (particularly the second one). Be sure to replace lines 6 and 7 with your actual ones (as well as the values, of course).
This also assumes your output directory is dist. Hopefully it is, because that’s the convention, but if you’ve got something else, you’ll need to update lines 1, 2, and 8.
I’m completely bypassing Codeship’s recommendation of handling the final git push via their own provided code (“include the commands from continuous-deployments/git-push.sh”).
Not a big deal either way, I just don’t see the need for an extra HTTP request.
I maintain a public repository on GitHub where changes are only made to a single YAML file. I'm looking for a solution to process that file on every push and generate files based on it. Essentially, a pipeline or CI should parse the file and create many different markdown files. These files (or more specifically, the changes to these files) should then be pushed back to the repository.
Requirements:
Manual changes to the YAML file and automatic changes to the markdown files should both be pushed to the master branch.
The version history should be kept (e.g. forced push might not work).
There is an arbitrary number of files that are generated.
There are Travis providers for GitHub Pages and GitHub Releases. But both have limitations that make them unsuitable for my requirements.
Using what tool/CI/pipeline can I achieve that on GitHub? I would prefer a service over a self-hosted CI.
Assuming that you already have the program/script to parse the YAML file and to generate the Markdown files, I can give you some insights on how I would do this from Jenkins CI. While I draw my experience from running my own instance, there are also hosted options such as CloudBees that you can explore.
Create a new Jenkins Freestyle project.
Under the Source Code Management section, configure your GitHub project coordinates.
Under Build Triggers section, activate the 'Build when a change is pushed to GitHub' option. That would launch the CI job at the moment you push a new version of the YAML file into the repository.
Under the build section, add an Execute shell build step.
In the shell step, launch the program or script that processes the YAML file/generates the .md files. End the script by adding the git add ., git commit -m "message", git pull and git push commands (assumes git is in the path).
Enable the new job to make it active in Jenkins.
You can do this now with the free GitHub Actions option for the repositories.
You need to put this step into your YAML file.
- name: Commit back to GitHub
run: |
git config --global user.name "github-actiuons[bot]"
git config --global user.email "41898282+github-actions[bot]#users.noreply.github.com"
git add -A
git commit -m "Updating some file"
git push
There are some items in the marketplace, but they didn't work for me.
The email of the bot is based on this thread:
https://github.community/t/github-actions-bot-email-address/17204
Update the commit message.
Be careful with the folder paths if you decide to push a specific file in a folder.
How is it possible that Travis the build failed for the latest push but passed the Pull Request?
On this Gist, you could find the failed and passed output log of the npm run build command that Travis gives. You could also find the configuration of Travis and here below:
install:
- npm install
- npm install -g angular-cli
language: node_js
script:
- gulp html
- gulp scss
- gulp ts
- gulp node
- npm run build
node_js:
- "6.9"
cache:
directories:
- node_modules
- bower_components
Background
This repository is configured in Travis CI to run tests on two environments - named pr and push.
A Pull Request (pr) build will be named continuous-integration/travis-ci/pr and from the docs:
Rather than test the commits that have been pushed to the branch the pull request is from, we test the merge between the origin and the upstream branch. To only build on push events, you can disable Build on Pull Requests from your repository settings.
A push build will be named continuous-integration/travis-ci/push and from the docs
Travis only runs a build on the commits you push AFTER adding the repository to Travis.
Solution
Since the merge of your branch into the base branch passed tests for continuous-integration/travis-ci/push, updating your branch to include the latest commits from the base branch will get your branch passing tests. From the image above, the GitHub UI should allow you to Update branch from the Pull Request page.
Caveat
With branch protections in place, it should be unlikely that your branch fails tests while merging into the base branch succeeds.
Be sure that you confirm that whatever was broken was actually fixed. That is, did someone "fix the build" by disabling that failing test in the base branch? As a cautious person, I would cherry-pick fixes into your branch to verify the problem is resolved.
By a comment of #osowskit, I've found the solution of the problem. He/she said:
PR will merge your changes into the base branch and run CI tests. Push will run CI tests on the current branch. Merging the base branch into your branch will likely resolve your build test on the branch.
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
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