• State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 74 subscribers
  • Views 3247 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287690
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF53: What files to add to project Git Repo

bbbakke

Sorry if this is a repeat ticket. I've done some searches and they result in information around Zephyr and RF Connect SDK Git repos and West usage to manages related source files and builds. But the search hasn't not yet reveled any info about what directories / files in my development environment I should be put in my project Git repo to be able to reproduce the build at a later date.

In my case, I used VSCode with the nRF Connect Extension Pack plugin and started with the peripheral UART sample created as a "workspace". So, I think my environment has all of the source files, moet cloned from versioned repos by west, and some files I am modifying or adding to the project.

So now I want to take what I have created and get it into a new project Git repo that I will manage on Github. But I don't know what directory to init my git repo, how to define my .gitignore (is there a standard nRF Connect SDK ignore file?), and what files to confirm are under source code management.

Any suggestions or pointers to info that defines how to manage my files with Git would be great.

-Brad

  • 0
    AHaug said:
    If you investigate the folders from your workspace setup and compare it to the SDK installation folder from the automatic installation you will find that they contain the same files, e.g you clone the entire SDK with the exception of the west.yml file within your application folder.

    Of course it clones of the nRF SDK, Zephyr, bootloadeer, etc., git repos, that is exactly the purpose of the "west" tool. But, more importantly, it clones exact and specific versions. That is the benefit of using west workspaces. When you have a multi-developer team, you don't want one on SDK ver 1.7.0, another on 1.9.99, and a third on the newest release made(hypothetically) this week. You want everyone on the same version and mange upgrades to newer version if and when appropriate. 

    AHaug said:
    Tech support at Nordic Semiconductor are a part of the engineering team, so you've already reached us.

    But we were not making any progress in our discuss so I hope you would reach out to others. 

    AHaug said:
    Managing the code base should give you some tips and tricks if you want to work with git based development and how the SDK folders are related through git and west as well as more info about how to instance 

    This sounds like a useful document, unfortunately I can't access it. Is this document public? Can you provide a link that is not in your "support-private" URL path?

    AHaug said:
    Brute force through deleting folders in the SDK, upload to git, clone back, pristine build and flash to see if it works. If it does not work, then there are some dependencies that causes you to require that folder.

    This is what I tried yesterday.

    • I initialized git with "git init" in the "PeripheralUART" directory.
    • I added a .gitignore with the build directory so it would be ignored.
    • I look at the files git lists as untracked.

    Guess what, none of the clone repos, nRF SDK, Zephyr, bootloadeer, etc., where listed. It was as if git was ignoring them even though they were not in the .gitignore. After some google searches and StackOverflow reading, turns out the thing you and I did not know is, git does automatically ignore any sub-folder that contains a .git folder (i.e., the sub-folder is already a repo so no need to track any files contain in it within the parent repo). 

    So the solution is to: 

    1. Create the initial project from the sample of choice in VS Code as a "Workspace" (a product development team should not use freestanding IMHO, and if you do, make sure the version of all other repos used in the build and toolchain are well documented if you want to be able to build it a year later for maintenance).
    2. Initialize your git repo in the parent directory of the project folder (where the .west folder exists).
    3. Add a .gitignore file:
      1. Ignore ".vscode" folders (Is this correct? Need to check.)
      2. Ignore "build" folders (I have a problem with this because ignoring the build directory means that the build configuration is not tracked in git, but I will take that up in a different thread). 
    4. Add all of the project folders and files, including the .west subdirectory which has the west manifest (config file). 
    5. Do the commit and push it (you will need to setup your remote URL).
    6. When you or a team member clones the project:
      1. Open the app project folder in VS Code (with the nRF Connect plugin installed of course)
      2. Open a nRF terminal (it has the correct env to run west commands)
      3. Run "west update" and it will pull in all the other required repos with the exact version everyone else is using. 

    Hope this helps others. Would be nice if the Nordic Team had this documented somewhere, maybe in the document link listed above that didn't work for me. Hopefully that link will be fixed / made public. 

    -Brad

  • 0 in reply to bbbakke

    Hi

    bbbakke said:
    This sounds like a useful document, unfortunately I can't access it. Is this document public? Can you provide a link that is not in your "support-private" URL path?

    The wrong url was pasted in the hyperlink. This should be the correct url to managing code base. Does it work?

    bbbakke said:
    turns out the thing you and I did not know is, git does automatically ignore any sub-folder that contains a .git folder (i.e., the sub-folder is already a repo so no need to track any files contain in it within the parent repo). 

    Then I learned something new aswell. Thanks for sharing!

    bbbakke said:
    So the solution is to: 

    1-2 sounds right.

    I agree that 3.a needs to be checked. It could be containing (just speculation about what could go wrong) some info about how the environment/paths is set up (similar to appdata for vscode) but this needs to be verified.

    3b sounds like a plan.

    4-6 I agree.

    bbbakke said:
    Would be nice if the Nordic Team had this documented somewhere, maybe in the document link listed above that didn't work for me

    I'll ask around the docs/product marketing team if we should make a guide/blog about this. Seems like its nice to have after you clarified some of the misunderstandings we had in this thread.

    Kind regards,
    Andreas

Related
Terms of service