I'm using render.com to build a NX project and all builds are tagged with "no branch" in NX cloud. How do I get the branch to show up in Nx cloud?
Need to set NX_BRANCH on CI platforms they don't directly support. For render.com, it would be:
NX_BRANCH=$RENDER_GIT_BRANCH npx nx build ...
Related
I have an app on Heroku. According to the Heroku App deploy guide I followed the below steps to modify the master.
Steps to make the push on Heroku
$ git add .
$ git commit -am "make it better"
$ git push Heroku master
The build of deploy was successful but the changes didn't reflect on the browser. I used hard refresh multiple times but didn't work.
If your app requires a build step to compress and combine assets and you are not seeing recent changes, then it's likely that you are forgetting to run that build step.
If you are using package such as parcel-bundler. you should run it before you deploy it. That would solve the issue.
You can read more on how to run it automatically whenever you deploy your app from here.
https://devcenter.heroku.com/articles/node-best-practices#hook-things-up
I want to set an opensource project where users can be sure that the deployed version .heroku.com corresponds with the actual source code in github master branch github.com/
Is there any way to prove a heroku deployment corresponds to a github repo?
Your app can spit out the latest deployed Git SHA if it has the "Dyno Metadata" feature turned on: https://devcenter.heroku.com/articles/dyno-metadata
Using that, you can show the latest SHA and compare it against the public repo.
Also, to add to what Jon said, you can do this via the heroku releases command. Every release, be it a code deployment, config var is 'tagged' - the command will show you everything that has changed on your app and a deploy will show the short git SHA, you can copy the SHA and then use the git command to search the repo for it.
eg.
assuming heroku releases returns
v10 Deploy 33f21247 foo#bah.com 2018/09/03 10:01:38 +0100
then you could do:
git cat-file commit 33f21247
which will then output the corresponding match, or a message saying it's not found. Obviously, this assumes your local repo is in sync with GitHub. To check it against GitHub you'd need to open your repo on GitHub like:
https://github.com/heroku/{projectname}/commit/{sha}
which will show the same commit on GitHub.
Sonarqube Server Version 7.0 (build 36138)
Sonarqube Branch Plugin 7.0 (build 413)
sonar-maven-plugin:3.4.0.905
Java project
Sonarqube is set up with a master branch already.
As part of a Jenkins build job we execute the following command:
mvn sonar:sonar -Dsonar.host.url=<our host> -Dsonar.projectName=<project name> -Dsonar.projectKey=<project name> -Dsonar.branch.name=${BRANCH}
where BRANCH is set to the branch name we are building in Jenkins.
Analysis appears to work when we build our "develop" branch in that the develop branch appears if it isn't in Sonarqube and the timestamp for the analysis is correct on the server, but there are two issues:
1) I've set "develop" to be a long-lived branch per the instructions in https://docs.sonarqube.org/display/PLUG/Branch+Plugin by modifying the long-lived branch regex in the SQ server to be:
(branch|release|develop)-.*
but I only see the Issues and Code tabs on the "develop" branch display. And in the Jenkins job, I see the message:
[INFO] Branch name: develop, type: short living
which leads me to believe that develop is not being recognized as a long living branch.
2) There is no output in the Issues tab. Only the code tab shows anything. But the master branch output shows 225 issues, so I would expect the same list of issues in the develop branch (since they haven't been addressed).
Questions:
Do long living branches show all of the same output that you
normally see for the master branch, including "Overview"?
Is there something that I need to do to specify the "develop" branch
as long-living in the maven command above?
Any idea why the issues tab doesn't show anything?
Many thanks,
Wes
In my opinion it is your regex you should check first. You are using the default (branch|release|develop)-.* notice that you have added hyphen(-) at the end.
So, sonar expects the branch name to be branch-, release- or develop-. In your case I believe the regex should be (branch|release|develop).*
Seems you hit this:
There's already a Jira ticket
https://jira.sonarsource.com/browse/MMF-1265
https://community.sonarsource.com/t/long-lived-branches-quality-gate-does-not-fail-in-first-analysis/175
Since travis-ci.org doesn't support bitbucket.org I need another CI service which supports it and allows managing the build commands in a VCS file (like .travis.yml in travis).
My quite annoying research result so far is:
semaphoreci.com: projects which are forks aren't listed even after refreshing the project list
app.shippable.com: signing up with both github.com and bitbucket.org doesn't work
codeship.com: doesn't support to run commands as ''root'' user((https://codeship.com/documentation/faq/root-level-access/))
www.snap-ci.com: no support for bitbucket.org((http://www.slant.co/topics/186/~hosted-continuous-integration-services))
I don't get why people would not want to share the CI service build commands in the VCS - chances of good collaboration without such a feature seems small to me. Even if one adds a script file in the VCS it still needs to be set up in the CI service which appears to be an unnecessary step.
A few months ago Bitbucket launched Pipelines. Quoting from the link:
Continuous delivery is now seamlessly integrated into your Bitbucket Cloud repositories.
You may use it on free plans, but next year they will reduce the build minutes for free plans from 500 minutes to 50 minutes as told in this link.
Also, CircleCI is supporting Bitbucket. It has free plan with 1500 build minutes. It can be triggered by commit or tag in BB. https://circleci.com/
The company that owns BitBucket also has a product called Bamboo for CI. Though most should work with any git that provides a webhook.
According to this blog, it is possible to use Travis-CI for Bitbucket:
Clone github repository:
git clone https://github.com/{github_user}/{github_repository}
cd {github_repository}
Add submodule bitbucket repository:
git submodule add https://bitbucket.org/{bitbucket_user}/{bitbucket_repository}
Add .travis.yml to root dir:
git:
submodules:
false
before_install:
- echo -e "machine bitbucket.org\n login $BITBUCKET_USER_NAME\n password $BITBUCKET_USER_PASSWORD" >~/.netrc
- git submodule update --init --recursive
$BITBUCKET_USER_NAME is bitbucket username
$BITBUCKET_USER_PASSWORD is app password
Open https://travis-ci.org/{github_user}/{github_repository}
A Semaphore CI user can add a fork of a project to his Semaphore account following these steps on the documentation page. Also, Semaphore is building a fork pull request and those builds are visible.
There also is (now) an option to use GitLab as CI/CD server for repository hosted on Bitbucket.
See the documentation here: on GitLab site
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events