GOA Systems

Category: Git

  • Use a build agent for multiple systems

    Assume you have a build agent that has a specific tool set installed. Let’s say certain compilers, build tools and configurations. Parts of the team work with Provider A (let’s say GitHub), others with Provider B (let’s say GitLab) and a third part works with the internal Git repositories and a locally installed Jenkins instance. The whole setup is running in a company network that is secured by a firewall and looks basically like the following diagram shows.

    The basic principle here is, that the agents connect to the service and thus from the network to the cloud provider and not the other way round. This way there is no route through the firewall required and as soon as the agent is up and running it connects to the cloud provider and appears as “online”.

    Advantages

    • All tools available and maintenance is only required once.
    • Each service runs as separate user and thus access to external entities can be managed (i.e. SSH access via public key)
    • Separate workspaces and access for analysis can be granted per team
    • Can be applied to Windows and Linux build agents
    • Per provider configuration is possible on local home directory usage (local toolset)
    • Scalable: Just clone the agent, change host name and connect to providers
    • Access to internal resources is possible for publishing and deployment for example

    Disadvantages

    • Single point of failure
    • Performance can be affected when all systems run builds at the same time.

    Challenges

    • Versioning for compilers when static compilers are required in the future (i.e. for firmware compilation on specific hardware) – Can be solved with Docker.

    Conclusion

    This article only scratches the surface of the topic but it shows that it is very easy to optimize usage of existing resources by connecting different cloud providers and thus allowing teams to work in their known environments. Additionally the ops team can manage the agents and keep the tools updated.

  • Fix ssh Git connection against Azure DevOps

    I recently had the issue against my on premise Azure DevOps server, that the clone via ssh would fail with the message:

    PS C:\Users\goa> git clone ssh://devops.example.com:22/GoaSystems/Java/_git/my.java.project %SERPROFILE%\workspaces\java\my.java.project
Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-rsa
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

    The error can look different depending on if you already have a configuration file for SSH or not. But in any case, if a error is thrown, it is likely that the keys are the culprit. Fortunately this is easy to solve. Create the following file

    notepad %USERPROFILE%\.ssh\config

    and add the following content.

    Host devops.example.com
    User git
    PubkeyAcceptedAlgorithms +ssh-rsa
    HostkeyAlgorithms +ssh-rsa
    AddressFamily inet

    Modify it of course with your specifications (i.e. hostname).

    One could ask why “AddressFamily inet”. Well, shame on me, I don’t have IPv6 not properly set up due to a lack of understanding. So now I rely on IPv4 (what this line configures) in order to not have to wait for a timeout every time I’d like to clone something.