A Clever Conversation on agile concepts, branching strategies and how to implement CI using issue branches in GitHub Actions

[lakruzz]

I just had a clever conversation that I'd like to share. It started out as question on agile concepts, but it turned out to be a full functioning solution to a very specific programming exercises I posted to the DAT students at KEA last Monday

Lars Kruse:

What are the most important concepts in agile software development

ChatGPT:

Agile software development is a methodology that emphasizes iterative and incremental development, collaboration, flexibility, and customer satisfaction. Here are some of the most important concepts in agile software development:

User stories: Agile development relies heavily on user stories, which are brief descriptions of features or functionality from the perspective of an end user. User stories help teams focus on what is most important to the customer.

Iterative development: Agile development is an iterative process that involves delivering small, working increments of software on a regular basis. Each iteration builds on the previous one, and the team receives feedback and makes adjustments as needed.

Continuous integration: Continuous integration is the practice of continuously merging code changes into a shared code repository and testing them as soon as possible. This helps teams catch and fix issues early in the development process.

Cross-functional teams: Agile development relies on cross-functional teams that include members with different skills and expertise. This helps ensure that the team can handle all aspects of the development process, from design to deployment.

Scrum: Scrum is a popular framework for agile development that includes specific roles, events, and artifacts. It emphasizes regular meetings, such as daily stand-ups and sprint reviews, to help the team stay on track and focused.

Lean principles: Agile development is heavily influenced by lean principles, which emphasize reducing waste, optimizing the whole system, and delivering value to the customer as quickly as possible.

Continuous improvement: Agile development is a continuous process of improvement. Teams are expected to reflect on their work and make adjustments as needed to improve the process and deliver better software.

Overall, the most important concept in agile development is to prioritize customer satisfaction and to continuously deliver value to the customer. This requires a flexible, collaborative approach that emphasizes communication, feedback, and continuous improvement.

Lars Kruse

Continuous integration is about merging code you say - is it a branching strategy or what?

ChatGPT

Continuous Integration (CI) is a software development practice that involves frequently merging code changes from multiple developers into a shared code repository. The goal of CI is to catch and address issues early in the development process, and ensure that all code changes are tested and integrated as soon as possible.

While CI does involve merging code changes, it is not necessarily tied to a specific branching strategy. However, many teams use a branching strategy, such as Gitflow, that is compatible with CI. In this approach, developers work on feature branches, and then merge their changes back into the main branch (often called the develop branch) when they are ready. CI systems can then automatically build and test the code on the main branch to ensure that the changes do not introduce any issues.

Some teams also use a trunk-based development approach, where all developers work on a single shared codebase, and changes are continuously integrated into the main branch. In this approach, developers are encouraged to make small, incremental changes, and to test their changes locally before merging them into the main branch. This helps ensure that the code is always in a stable state, and that issues are caught and addressed quickly.

Regardless of the branching strategy, the key to successful continuous integration is to ensure that code changes are integrated and tested frequently, and that any issues are identified and addressed as soon as possible.

Lars Kruse

Ehhh? GitFlow has multiple long-lived branches - even the original author (NVIE) says himself, that it's a process optimized for roll-backs - not continuous delivery - did you mistake GitFlow for "GitHub Flow" or perhaps "GitLab Flow"

ChatGPT

You are correct, my apologies for the confusion. GitFlow is a branching model that involves multiple long-lived branches, and it is not necessarily optimized for continuous delivery. Instead, it is focused on managing releases and supporting rollbacks.

GitHub Flow and GitLab Flow are two branching strategies that are more closely aligned with continuous delivery. GitHub Flow involves working directly on the main branch and using pull requests to manage changes, while GitLab Flow involves a similar approach but also includes separate branches for testing and staging environments.

Regardless of the branching strategy used, the key to successful continuous integration and continuous delivery is to ensure that code changes are integrated and tested frequently, and that any issues are identified and addressed as soon as possible. This helps ensure that the code is always in a stable state and that new features and bug fixes can be delivered quickly and reliably.

Lars Kruse

Could you show me an example of a workflow in GitHub Actions (YAML) that will trigger when an issue branch is pushed and which will merge the branch onto master and run a build and perhaps a unittest and deliver (push) to GitHub if everything is OK?

ChatGPT

Sure! Here's an example GitHub Actions workflow that triggers when an issue branch is pushed, merges the branch onto master, runs a build and a unit test, and pushes the changes back to GitHub if everything is successful:

name: Issue Branch Workflow

on:
  push:
    branches:
      - 'issue/*' # Trigger only when a branch with name starting with 'issue/' is pushed

jobs:
  merge_and_test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Merge branch onto master
        uses: rtCamp/action-merge-request@v1
        with:
          source_branch: ${{ github.head_ref }}
          target_branch: 'master'
          github_token: ${{ secrets.GITHUB_TOKEN }}
          
      - name: Build and test
        run: |
          # Run build and test commands here
          # Example: 
          echo "Build and test step"
          exit 0
          
      - name: Commit and push changes
        if: success()
        run: |
          git config --global user.email "[email protected]"
          git config --global user.name "GitHub Actions"
          git add .
          git commit -m "Merge issue branch and run tests"
          git push origin master          

This workflow includes four steps:

The first step checks out the code from the branch that triggered the workflow.

The second step uses the rtCamp/action-merge-request action to merge the branch onto the master branch. The action requires specifying the source and target branches and a GitHub token. In this example, we use the default GITHUB_TOKEN secret.

The third step runs the build and test commands. You can replace this with your own build and test commands, or use an action from the GitHub Marketplace to run tests.

The fourth step commits the changes and pushes them back to the master branch if the build and test step was successful.

Note that this workflow is just an example, and you may need to modify it to fit your specific needs. For example, you may need to include additional steps for deploying your code or sending notifications. Additionally, you should ensure that you have appropriate permissions to merge branches and push changes to the master branch before using this workflow in a production environment.

Lars Kruse

Thanks - a word of precaution though: v2 of the action/checkout generates a warning, it instructs me to use v3 instead.

And I don't know the action rtCamp/action-merge-request who wrote that? Can I trust it? It's not a GitHub verified action?

What would the merge step look like if I wanted to use only native git commands ort GitHub verified actions?

ChatGPT

You're welcome! Thank you for letting me know about the warning from action/checkout - yes, it's best to use v3 instead if possible.

Regarding rtCamp/action-merge-request, it's a community-maintained action and is not a GitHub verified action. You can check the repository and the community feedback to assess whether or not it is trustworthy. Alternatively, you can use native Git commands or GitHub Actions that have been verified by GitHub.

Here's an example of how to use only native Git commands to merge the branch onto the master branch:

name: Issue Branch Workflow

on:
  push:
    branches:
      - 'issue/*' # Trigger only when a branch with name starting with 'issue/' is pushed

jobs:
  merge_and_test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Merge branch onto master
        run: |
          git checkout master
          git merge --no-ff "${{ github.head_ref }}"
          
      - name: Build and test
        run: |
          # Run build and test commands here
          # Example: 
          echo "Build and test step"
          exit 0
          
      - name: Commit and push changes
        if: success()
        run: |
          git config --global user.email "[email protected]"
          git config --global user.name "GitHub Actions"
          git push origin master

In this example, the second step uses native Git commands to checkout the master branch and merge the issue branch onto it using the --no-ff flag, which ensures that a merge commit is created.

Again, note that this workflow is just an example, and you may need to modify it to fit your specific needs. Additionally, you should ensure that you have appropriate permissions to merge branches and push changes to the master branch before using this workflow in a production environment.

Lars Kruse

Lovely - Thanks (except you still suggest actions/checkout@v2 you should up that to actions/checkout@v3

ChatGPT

You're welcome, and thank you for the heads up! You're absolutely right - it's best to use actions/checkout@v3 instead of actions/checkout@v2. Here's the updated workflow:

name: Issue Branch Workflow

on:
  push:
    branches:
      - 'issue/*' # Trigger only when a branch with name starting with 'issue/' is pushed

jobs:
  merge_and_test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Merge branch onto master
        run: |
          git checkout master
          git merge --no-ff "${{ github.head_ref }}"
          
      - name: Build and test
        run: |
          # Run build and test commands here
          # Example: 
          echo "Build and test step"
          exit 0
          
      - name: Commit and push changes
        if: success()
        run: |
          git config --global user.email "[email protected]"
          git config --global user.name "GitHub Actions"
          git push origin master

Thank you again for catching that!

Lars Kruse

You're welcome - I need i bit more help - specifically with the filter you use to catch the issue branch.

GitHub generates issue branches that are prefixed with the user's GitHub handle, then a forward slash then the keyword 'issue' and then finally the integer which is the id of the issue. Let me give you a few examples: My handle is lakruzz so if I had an issue branch on issue 15 it would be lakruzz/issue15. Let´s say your handle was chatgpt and you had an issue branch on issue 145 then your branch would be chatgpt/issue145 can you help me: what would the branch filter look like, if it were to catch all issue branche regardless of userhandle and issue number?

ChatGPT

Sure, I can help you with that! If you want to catch all issue branches regardless of the user handle and issue number, you can use the following branch filter:

branches:
  - '*/issue*'

This will match any branch name that contains the string "issue", regardless of the prefix before it. Here's the updated workflow:

name: Issue Branch Workflow

on:
  push:
    branches:
      - '*/issue*' # Trigger only when a branch with 'issue' in the name is pushed

jobs:
  merge_and_test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Merge branch onto master
        run: |
          git checkout master
          git merge --no-ff "${{ github.head_ref }}"
          
      - name: Build and test
        run: |
          # Run build and test commands here
          # Example: 
          echo "Build and test step"
          exit 0
          
      - name: Commit and push changes
        if: success()
        run: |
          git config --global user.email "[email protected]"
          git config --global user.name "GitHub Actions"
          git push origin master

I hope this helps! Let me know if you have any further questions.

Lars Kruse

Naah, your're good! I couldn't have come up with a better solution myself, And I've been doing this stuff (declarative pipelines) for many years - so I'll salute you as a genuine hacker - and that's a compliment!

ChatGPT

Thank you for your kind words, I appreciate it! I'm glad I could help you out, and feel free to reach out if you have any further questions or concerns. Happy hacking!