Has any one integrated the GIT with bigfix? If bigfix root server check out the file from GIT and see its new version then run the task.
Relevance should depend on the new version of the checked out file from GIT.
4 Likes
Thatâs on our roadmap⌠highly interested.
we will be deploying it soon. Let see how it goes.
would love to know, if there was was any progress on this one
Iâd like to better understand the integration use case here. What would you be looking for from an integration with GIT?
@dconnol1, @JasonWalker posted a repo with a custom plugin to download from GitHub (link), Iâve only ever spent 2-3 hours but couldnât get it to work with Azure DevOps (probably issue on my side as I just didnât have enough time). There was recently a discussion here of someone asking how to integrate git in the process and suggestion was to write a script that pulls content puts it in a folder and then schedule periodic âsyncâ but all manual, nothing integrated/automated.
Hi @Aram , I do have our documented in the RFE but as far as we are concerned there are need for two separate use cases:
-
The more-straight forward one is something along the lines of what Jason provided where support for âdownload latestâ from a repo or folder in a repo, so when you run an action root server makes grabs the latest version of a script/binary/etc and performs the process around it. This will essentially open the door for content developers to store and track their stuff in GIT repos outside of BigFix (for example, if there is a bug in a new version I can track within the repo who did what where; it can be easily reversible; it opens the door for streamlining automation of custom content, especially repetitive ones - not every single software is patchable by BigFix out-of-box and when we create a manual fixlet for it the tedious bit is that every month/quarter/half-year/year we have to recreate that for their latest version where the only thing that changes is version number, which is built into relevance/success criteria, and the binary but everything else is copy/paste, so âautomatic grabâ of the file + version and having that dynamically referenced in actionscript solves it)
-
Bigger and a lot more involved use case is fully-fledged integration with GIT Repo.- the way I envision this is Git-based custom sites where the repo is the site and irregardless of where you make the change from (console, GIT client, GIT command-line tool, etc) all that is syncâed into the repo and to root server respectively. Important aspect should be ability for BigFix to display the history from GIT and use it (for example, ability to view changes to a fixlet - what was changed; who changed it; when; and even run older version of that fixlet if you chose to; ability to âsyncâ baseline to specific version of a fixlet). The way I see it - this would truly add version control, auditing and compliance to content management side of the system that is currently lacking, not to mention external integrations for development processes (a ton of Agile/DevOps/etc tools integrate with GIT and provide the perfect combination of issue tracking & development-to-release tracking). It can also open the door of custom data fields around fixlets with the tagging/custom properties.
Happy to discuss further if required but to sum it up - this kind of integration would truly be a game-changer!
2 Likes
Weâre also being pushed by our DevOps folks to be more ârepo-integratedâ. They tend to see systems that arenât integrated as âlegacyâ.
Having flexibility to use either native internal content or repo content would be a huge step for Bigfix.
Ideally it would be repo agnostic. GIT, BitBucket, etc, at least the major players should be supported.
The side benefits of version control and history would be amazing too. It would address some of the most significant gaps that Bigfix has today IMHO.
cc: @Aram
5 Likes
One potential roadblock to this repo integration concept is the fact that BigFix doesnât allow the developer of custom content to manage and control the content ID. For example, when new custom fixlet is created, the Fixlet ID is populated with the next available ID number, such as 184. The next custom content that gets created will have as its ID 185, and so on. In my opinion, giving customers the abilitity to specify the ID is criical to integrating with a repository. See the idea here: Allow customers to specify the Content ID of | HCL BigFix Ideas Portal (hcltechsw.com)
2 Likes
@itsmpro92, good call, Boyd but I donât think it will be a major problem. HCL can and clearly are doing it with external sites, so ID of fixlets control must exist somewhere in the code and just be restricted/not enabled for custom sites.
This actually reminds me of something else - it would be amazing if the integration can support multi-environments by allowing you to associate them with branches of the same repo - for example, âmainâ branch is associated with all your environments, so âapprovedâ content is automatically there & âdevâ branch is only associated with the development environment. You develop stuff in âdevâ, so that is only visible in your dev BigFix environment for testing and once you are happy and do the âmergeâ to âmainâ branch that essentially automatically promotes the content.
5 Likes