GitLab has a tool, CI Lint, which can be used to validate and check CI/CD syntax for GitLab Pipelines.
Does GitHub have an equivalent tool for GitHub Actions?
I have searched but cannot find any equivalent so far...
A bit of this is mentioned as a comment on your initial question, but I personally use the following:
When building my pipeline I use the yaml extension provided by RedHat
for VSCode. This uses the JSON Schema store to validate the yaml
syntax used by GitHub Actions.
https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml
https://www.schemastore.org/json/
My repositories us the GitHub provided super-linter action available on the marketplace to lint my github actions files. This
includes a basic yaml linter, but also actionlint (as mentioned in
the comments above) which would apply to your github workflows. These
can be ran locally, but I tend to rely on the intellisense within
VSCode locally, and the linters within GitHub.
https://github.com/marketplace/actions/super-linter
https://github.com/rhysd/actionlint
Related
I'm trying to get reporting working for Karate DSL, and it's proven a challenge because my team uses Circle CI instead of Jenkins. Cucumber reporting seems to only work for Jenkins.
I've had a look at this documentation, here:
https://github.com/intuit/karate/tree/master/karate-demo#example-report
https://github.com/jenkinsci/cucumber-reports-plugin
I was wondering if there is a circle friendly equivalent you could recommend? It'd be even better if the reports could be generated in the terminal. It's going to be a hard sell to convince my team to change CI tools just so I can implement a test framework.
Thanks!
Here's what I suggest:
If you follow the demo / doc instructions - you will get the HTML reports in say target/cucumber-html-reports, and this is "pure Maven and Java", no dependency on CircleCI at all so far.
Now all you need to do is somehow make these HTML reports accessible via the web. In Jenkins, there is an HTML Publisher Plugin. I am not familiar with CircleCI but a quick search suggests that there is a way to expose links to build artifacts.
Also note that when you follow the demo, Java JUnit XML reports would also be output to target/cucumber-reports. It looks like CircleCI has support for these which means that it should be able to derive the build pass/fail status and stats if configured right.
Also note that Karate now enables you to write custom reports: https://stackoverflow.com/a/66773839/143475
I know VS2017 now natively supports ESLint which is working fine for me. I need to know if is it possible to integrate ESLint with MSBuild so that I can have the same linting experience not only on my development workstation but on TFS CI/CD system too? Looks like there are some supported integrations as mentioned here but nothing on MSBuild.
I need to know if is it possible to integrate ESLint with MSBuild so
that I can have the same linting experience not only on my development
workstation but on TFS CI/CD system too?
So far, MSBuild does not integrate ESLint.
Besides, l found no official MSBuild document about Integrating ESLint. Also, I did a small test for Build Tool for VS2017, l found that there is no such component called ESLint which proves that it is not supported by MSBuild.(l also did in Build Tool in VS2019 and it is the same as in Build Tool for VS2017)
In addition, although MSBuild does not support ESLint, I think your proposal is an interesting idea and you can suggest a feature to user voice(DC Forum).
After that, you can put the link here and we who interested in this will vote it so that it will call the attention of the Support Team.
Hope it could help you.
We are currently using bamboo to build and test our software. Now our build plans are just a bunch of task: execute this bat, execute that bat etc. Created with the Bamboo UI.
It happens that over months/years the build plan needs adjustments:
Parallelize jobs
Add extra jobs
Change some tasks
But this will break when we try to build an older version of the software. Some scripts (called from bamboo task) are not-existing in older versions.
At my previous employer we used Jenkins pipelines where the content of the build and test was just a file present in the sources repo.
Now with bamboo it appears you can use Bamboo Specs. From I read you create specs file and when you run this, it which will create build plan. But I don't see a relation to cater for changing build plans over time (changing steps).
For example the Bamboo Specs of develop are used to build all Plan Branches (e.g. Pull Requests). So if you want to change the build in a PullRequest, you first need to merge this into develop, the Bamboo Spec of develop updates the Build Plan. Not possible to test this before merging.
Question: How can you make scripted buildplans in Bamboo, where every branch of develop can a have possible other way of building?
We have it now setup as:
Buildplan 'Product A': plan branches: develop, release_x, release, y
Buildplan 'Product A PullRequest': plan branches: feature/*
Edit: supported in 7.0: https://confluence.atlassian.com/bamboo/enhanced-plan-branch-configuration-996709304.html
Old answer:
I found Atlassian documentation: https://jira.atlassian.com/browse/BAM-19620. They call it 'divergent plan branches'. No support, there is a feature request.
As of 15-4-2019:
Atlassian Update – [11 April 2019] Hi everyone,
Thank you for your votes and thoughts on this issue.
We fully understand that many of you are dependent on this
functionality.
After careful consideration, we've decided to prioritise [this
feature] on Bamboo roadmap. We hope to start development after our
current projects are completed.
Expect to hear an update on our progress within the next 6 months.
To learn more on how your suggestions are reviewed, see our updated
workflow for server feature suggestions.
Kind regards,
Bamboo Team
Question: How can you make scripted build plans in Bamboo?
To make scripted build plans in Bamboo, you have to use bamboo specs. Since you are already familiar with Jenkins, bamboo specs work exactly like Jenkinsfile by automating your pipeline. The benefit of using this is that it lives in your source code and the changes you make to this file in your source code automatically changes your plan(pipeline) when bamboo build is triggered.
This is how I script build plans in bamboo:
I add my bamboo.yml file under the root of my repo. But currently, I use git subtree and my bamboo specs live in there. But you don't have to do this. The below link provides you with a simple approach.
Link my repo to bamboo
Tell bamboo to scan for bamboo specs in the repo
Make commit and push
https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-yaml-stored-in-bitbucket-server-941616819.html
If I have to make changes to the plan in the future, I edit the bamboo specs file then commit and push.
I had the same problem and unfortunately had to go through an unpleasant choice
Backporting the build script
This is not necessarily feasible everywhere, but I managed to make it work somehow for my project.
The idea is: treat the build script as a C#/Java interface, or better as a contract.
As soon as your branches do not provide significant changes in building the software, e.g. your desktop app becomes a web app, or you switch from Ant to Gradle, you can handle this.
Assuming my application is always a web application to be released as a jar on JFrog Artifactory, I have identified the following steps that are common to all maintained versions:
Use javac to build the jar of all modules
Use gulp to build the Javascript resources
Run JUnit from the repository
Baptize 💒 the artifacts with a version number obtained with a tricky algorithm
Push the artifacts to JFrog Artifactory
So the idea is that I had taken my Ant build script and mostly rewrote it in order to do the same tasks on different versions of the application. I started doing the changes from an older version, not maintained anymore, as an excercise. In fact, my official Git branches look like release/x.y.z where semver is x.y.z.k and newer bugfix-builds are built from the head of any x.y.z release.
So I took release/3.10.0 branch and rewrote Ant. I am currently testing with a manually created Bamboo plan
Stage: Compile
ant clean ivy-retrieve compile jar #builds the jar in a job
ant gulp-install gulp-prod zip #creates javascript resources
Stage: Test
ant run-junit
Manual Stage: Release
ant baptize ivy-release #tags the artifact using ${bamboo.jira.version} and pushes to JFrog Artifactory
What I am going to do with Yaml
Since the build script is the same, but specific tasks (e.g. Java compiler version) may change in different versions, I can create a very single Yaml script that rules them versions all.
I will then merge release/3.10.0 => release/3.10.1 => release/3.10.2 ... release/3.11.2 by merging the conflicts
Personal experience
Tonight I am struggling in making the JUnit tests work as I also chose to backport my testing framework to the older version of the project. I accept that a few tests will fail because older and non-maintained versions contain bugs. For me this is a way to prove that the system works.
Indeed, diverging branches are a great idea, but I am forced to use Bamboo 6 in my office
is there a way to notify a CI system about a new published version of an artifact and trigger a build?
The scenario looks like that:
Developer of team A working on component C commits changes
CI is triggered, builds and runs tests
After tests are passing the binaries are published to an artifact repo (Nexus)
Another CI job receives this notification and triggers a build where other components + the new component C version are tested (integration tests).
Is there any plugin available on the market that supports such a notification mechanism? I haven't found yet such a tool for Nexus(Ivy)? The only thing I found is an Artifactory plugin from JFrog where you can publish from Teamcity directly.
Thanks,
Martin
I'm not aware of anything pre-made that does this. But you could easily write a small plugin that does this. Have a look at the "virusscan" example here, it would just take a few small modifications to make it do what you want:
https://github.com/sonatype/nexus-example-plugins/
Artifactory nowadays supports webhooks to achieve what I asked years ago: https://www.jfrog.com/confluence/display/JFROG/Webhooks
Is it possible to publish your site reports to github? For instance, I run Checkstyle, Findbugs, Cross Reference, and other plugins and would like to have that publicly available. Since my project is already there, I'd like to just keep it there.
With the state of the plugins that exist now, you'd have to do some shimming. The site command (per your comments: wanting to use mvn:site) has a mechanism (stage) for pushing the resulting site somewhere, but it's all mostly predicated on SCP'ing it around to some final destination. For github, I don't think there's any obvious place to land things like that.
The solution would be to write something that extended the site plugin to check in the results to Github using the github pages functionality. Details on the github pages bits are available at http://pages.github.com/. To get there, you'll be writing something that checks in your resulting site to a root branch "gh-pages" and going from there.
There are maven github plugins wich works fine for me.
feature:
deploy artifacts
download artifacts
deploy site to gh-pages
See: https://github.com/github/maven-plugins and fork the example project at https://github.com/kevinsawicki/github-maven-example to try out.
The Maven way to publish your reports would be to build the Maven site and to deploy it using FTP, SCP or DAV.
I don't know if GitHub provides hosting space and supports any of this protocol. If it does, then the following resources will help:
Deploying a Site in the site plugin Usage page
10.6. Deploying Your Project Website
Maven 2: Getting "mvn site:deploy" to work
Releasing Maven projects to Github
Site Distribution in the POM Reference
If it doesn't, better look for another place to host your site.
I'm using this plugin for that: http://synergian.github.com/wagon-git/