element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Code Exchange
  • Technologies
  • More
Code Exchange
Blog GitHub Actions: my automated flow for Pico GPS project with Teseo (validate, deploy, publish docs)
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Code Exchange to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Jan Cumps
  • Date Created: 5 Aug 2024 8:59 PM Date Created
  • Views 202 views
  • Likes 5 likes
  • Comments 0 comments
  • github.io
  • github
  • teseo_c++
Related
Recommended

GitHub Actions: my automated flow for Pico GPS project with Teseo (validate, deploy, publish docs)

Jan Cumps
Jan Cumps
5 Aug 2024

I wrote a series of articles about GitHub Actions. To:

  • validate that no one submits code that breaks the build
  • automate nightly deploy and update online documentation

The flow below shows the current setup.
Read it down to up, to understand what automations are happening during a development cycle.image

  • A developer that works on a new feature is never blocked. There are no automations, but they can run the existing validations manually if wanted.

  • When the feature is tested by the developer, and deemed mature, the developer creates a pull request. At that time, the first validation kicks in:
    If the code breaks the build, the pull request will fail.
    A build break at that time would impact the whole team. Buggy code in your feature repo is OK. But when you consider your code "ready for upstream", it should build.
    When that's successful, the development branch manager can accept the pull request and merge it to the development branch.

  • If that's successful, a new set of firmware binaries is built, and uploaded to the GitHub nightly release. (action, not validation)

  • When it's time to cut a new release, the development branch manager will create a pull request from development to master. At that time, another validation kicks in:
    If the code breaks the build, the pull request will fail.
    A build break at that time would impact the next release.
    When that's successful, the main branch manager can accept the pull request and merge it to the main branch

If that's successful, DoxyGen will re-generate the documentation, and publish it to github.io. (action, not validation).

Note: this approach doesn't slow down a developer while developing. They can check in incomplete or buggy code to the feature branch.
Developers should get the value of version control, and check in often. Without hurdles.
But it 'll ensure that when the job is (deemed to be) complete, due diligence is done before requesting integration into the official code base.

Link to all posts.

  • Sign in to reply
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube