How to create a GitHub repository compatible with KiCAD?

Ok I changed the name of the icon into icon.png
for the metadata.json yes sure.

Please here it is
metadata.json (1.1 KB)

EDIT/ I found why :slight_smile: I posted the corrected JSON

I forgot to write “library” at the place of “colortheme”

now the validation passed

Now what should I do please? What’s the next step?

Now that you have a valid package and metadata you can open a Merge Request on the metadata repository. Just keep following the steps in the readme of that repo. If you are not very familiar with git and some steps are unclear then you can just use the gitlab UI to make the merge request and we will help you with the rest.

Important thing is that you put your metadata.json and icon.png files under packages/com.github.tormyvancool.NuovaElettronica in that repo.

1 Like

ok I will do it right tomorrow :slight_smile: I’m very happy for this :slight_smile:

For the metadata.json and icon.png I uploaded them right now
Please check if everything is fine

If it passes validation then it’s fine at this stage. Any additional checks will be part of merge request review.

ok perfect.

I have to understand the documentation in the process about the push.

What i do normally (when I collaborated for few things in other projects) is to create a branch, make the modification to my branch then commit the mods.

It’s not clear (in this moment) if I have to do so. I wouldn’t want to make somebody mad with me :smiley:

Yes, that’s the standard practice and what is expected here as well.

1 Like

Ah nice.

And in case of new release? Just I update on my branch and I commit and push the update?

In simple terms, yes, you update your metadata to have new version (you can keep the old one alongside the new one or remove it, up to you), update your branch and open new merge request with the changes.

But there are a few things hiding behind “update your branch” here and depending on how familiar you are with git this can get a bit tricky. To be more specific you have to

  1. Get your checkout’s main branch up to date with upstream
  2. Create new branch from current tip of main
  3. Make your changes there, commit, push to fork
  4. Create merge request from fork’s branch to upstream repo

If you don’t know how to do some of the above I can provide specific git commands. If you don’t want to use git command line you can do all of the above from gitlab ui too.

1 Like

Ok please I’ve done this:

Merge Request

Pipelined

EDIT: Happy Easter

What to do now?

Should I redo the merge request?

No need to redo the merge request, just make changes suggested by reviewer, create new commit with the updated metadata and push that to gitlab. Merge request will automatically pick up the new changes.

ok I have made the change about 8.0.
Now I read what he ment for the URL and I wil change it accordingly.

Please tell me if I’m correct:

afte have made the changes (and validated them … it means updated my GitHub as well):

  • go to my fork GitLab
  • update the metadata.json

… and what else?

NOTE: I have very few practice with GitLab and I use the web interface.
Please consider to guide me step-by-step.

NOTE 2: of all the suggestion you gave me (include corrections), I took not in my one-note so that next time I will follow it up very carefully

On your fork simply edit metadata.json of your package and commit the changes. They will be reflected in the merge request automatically.

I see that in this instance you have changes on main (default) branch so you will not have to change branches before editing. But normally you should create a separate branch and make your changes there. It will make it easier to keep main up to date. But this is only relevant for future updates or other packages you add.

Ok I updated the metadata.json and committed it right now.

About the “main branch”.
Well I tell you what I also normally do, but as I said, i never worked on big projects, just small ones where we had to work 2 or 3 max.

The vast majority of the time I’m alone … so I work on local directories then I just commit and push. hence on several things I have not familiarity with.

so what I did here in GItLab is:

  • I created a Fork
  • I created into that fork my folder into the /packages, after have seen what the other ones have done and how (my reference was the Elektuur since it inspired me for my Library. Personal note: I was reader of both: Nuova Elettronica and Elektuur/Elektor :slight_smile: )
  • With the use of the web interface, I uploaded the 2 files: metadata.json and icon.png
  • Then committed with a title
  • Then opened a Merge Request

But from what I understand form your talking, there should be a kind of intermediate step I’m not familiar with, but I want to learn it.

At that point the web interface asks you the target branch. It is common practice to create a separate branch for each merge request you make. Since you didn’t specify new branch it used the default “main” for you.

Everything else is correct.
For next update, since you already have a fork, instead of creating new fork you should update your main branch of the fork. From the web ui you can simply click “Update fork” button on the main page of your fork. It will only show up if your fork is behind upstream.
After the update proceed with edit->commit to new branch->create merge request, as usual.

Once you already have a merge request and want to make changes to it (because reviewer requested them or you need to fix something) then do following:

  1. In your fork home page switch from “main” branch to the branch you created for the merge request.
  2. Make the edits, commit to the same branch
    That’s it, merge request will be updated.

The importance of having each merge request to be on separate branch only comes into play with large teams making simultaneous changes to the repo. If you don’t do that then earlier or later you will run into a situation where you can’t easily update your fork because of merge conflicts and gitlab web UI is not good enough yet to provide means to deal with them. You will either have to get busy with git cli, which can be daunting for someone unfamiliar with how git works, or abandon your fork and create a new one.

1 Like

I will try it with another project just made on purpose, to get more confidence

Now, i see @craftyjon has approved the merging (thank you :slight_smile: ). What are the next steps?
How will it be available to users? Via Plugin & Content Manager?

P.S. I hope do not have made other troubles :smiley:

Just wait, it will appear in official repository within 24 hours and will be available in the plugin manager.

1 Like

So: good news: it appeared and I installed in on another machine to avoid conflicts on my main one

I finally understood now that “PCM_” as prefix, stands for “Plugin & Content Manager”

That’s great. thank you for your help/support.

NOTE: I have made a theme and now I have created the Branch as you told me. Then I have made the MR

EDIT: another question always related to the repository for KiCAD

In 2021 I have made a Project Template for the Series 500. It was one of the first things I learned in KiCAD because I really need it.
Here the old topic [I SOLVED IT] Template for 500 Series rack mounted audio modules?

From that moment on, that template is available from my GitHub.

My question now is: is it possible to have it merged in KiCAD itself so it’s automatically available for anyone that needs for this template?
It’s very used in Pro-Audio systems.

At the moment project templates are not distributed with plugin manager but you should be able to contribute your template here KiCad / KiCad Libraries / KiCad Templates · GitLab and it will be available in next kicad release.